Sorry in advance, if I broke some etiquette rules of list cross posting!! ------------------------------------------------------------------------- Posted to linux-cluster and cluster-devel only because I saw a previous email that did this also and it seemed to make sense, given the nature of the request. Hi All, I've just had a GFS volume massively corrupt itself. Whenever the cluster tried to mount the GFS volume CPU utilisation went to 100% or greater (multi-core cluster nodes), and it would never mount. So I've run gfs_fsck against the volume and sure enough it's found problems. It could be over 100,000 of them (a guestimate from the indicated output of gfs_fsck). At this point the, being quite pragmatic, I'm of an understanding that the filesystem might be dead and I may need to recreate it. However I wanted to see if the filesystem was worth keeping even if the data on it was suspect. During the gfs_fsck run I'm receiving the following messages: ondisk and fsck bitmaps differ at block 120968515 Fix bitmap for block 120968515? (y/n) y Succeeded. ondisk and fsck bitmaps differ at block 120968516 Fix bitmap for block 120968516? (y/n) y Succeeded. ondisk and fsck bitmaps differ at block 120968517 Fix bitmap for block 120968517? (y/n) So you hit 'y' and hit 'Enter'. Here's what happens if you just hit Enter though: ondisk and fsck bitmaps differ at block 120968518 Fix bitmap for block 120968518? (y/n) Bad response, please type 'y' or 'n'. Fix bitmap for block 18446744073709551615? (y/n) Bad response, please type 'y' or 'n'. Fix bitmap for block 47506943251024? (y/n) Bad response, please type 'y' or 'n'. Fix bitmap for block 254545062656? (y/n) Bad response, please type 'y' or 'n'. Fix bitmap for block 1? (y/n) y Succeeded. ondisk and fsck bitmaps differ at block 120968519 Fix bitmap for block 120968519? (y/n) Apart from the fact that the 'Fix bitmap for block' number keeps changing, even though the the last two lines indicate that gfs_fsck was still talking about block 120968518 (because it proceeds on to block 120968519 immediately after you tell it 'yes') - there is no way to tell gfs_fsck to "Fix all". Having to manually type 'y' and hit 'Enter' for each individual block is, quite frankly, annoying (not to mention a repetitive stress injury when 100,000 potential blocks/200,000 key strokes are concerned!! :-) Is there any way for the user to say "Yes to all"? At least if the default choice was "Yes" when the Enter key was pressed, the user could hold down the Enter key until the entire list of blocks had been fixed. Regards, Stewart -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
