Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Tue 2007-05-29 13:05:29, Neil Brown wrote: > On Monday May 28, [EMAIL PROTECTED] wrote: > > On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote: > > > Right. Could we get more helpful message here? 'Filesystem check on > > > next boot on AC power'? > > > > So "(check deferred; on battery)" wasn't explicit enough? I guess I > > assumed that users would understand that the opposite of "on battery" > > was "on AC power". I guess I could say "(check defferred 'til on AC > > power)" if people think it would be clearer. > > > > So when I use my travelling power adapter which I plug into the 12V-DC > power in my car, and it delivers DC power to my notebook. > My note book tells me that I am using AC power > > I really think "AC" as the opposite of "battery" is wrong and should > be stamped out everywhere, certainly not introduced here. > "external power" maybe? Well, on one sunny day, we'll want to tell the difference between "cheap" power and "expensive" power. zaurus running on AC or car adapter is "cheap". zaurus running from external notebook's battery is something in between -- given that notebook battery should keep zaurus powered for few weeks. zaurus running on external 4xAA batteries or on internal li-ion is "expensive". ...but I'm afraid it will take long time before we can worry about that. > Check deferred until system is externally powered. Check deferred; on battery is completely fine; I just did not see that message for some reason. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
Hi! > > Right. Could we get more helpful message here? 'Filesystem check on > > next boot on AC power'? > > So "(check deferred; on battery)" wasn't explicit enough? I guess I > assumed that users would understand that the opposite of "on battery" > was "on AC power". I guess I could say "(check defferred 'til on AC > power)" if people think it would be clearer. I did not see the "check deffered; on battery" message. Either I'm blind, or am using too old fsck. Sorry for noise. > > Or maybe keep counting, and when we reach 2x mount-count-limit, > > force a fsck, battery power or not? > > We do that already. It's just tough to make that all fit on an 80 > status message. :-) Great, sorry for more noise. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Monday May 28, [EMAIL PROTECTED] wrote: > On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote: > > Right. Could we get more helpful message here? 'Filesystem check on > > next boot on AC power'? > > So "(check deferred; on battery)" wasn't explicit enough? I guess I > assumed that users would understand that the opposite of "on battery" > was "on AC power". I guess I could say "(check defferred 'til on AC > power)" if people think it would be clearer. > So when I use my travelling power adapter which I plug into the 12V-DC power in my car, and it delivers DC power to my notebook. My note book tells me that I am using AC power I really think "AC" as the opposite of "battery" is wrong and should be stamped out everywhere, certainly not introduced here. "external power" maybe? Check deferred until system is externally powered. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote: > Right. Could we get more helpful message here? 'Filesystem check on > next boot on AC power'? So "(check deferred; on battery)" wasn't explicit enough? I guess I assumed that users would understand that the opposite of "on battery" was "on AC power". I guess I could say "(check defferred 'til on AC power)" if people think it would be clearer. > Or maybe keep counting, and when we reach 2x mount-count-limit, > force a fsck, battery power or not? We do that already. It's just tough to make that all fit on an 80 status message. :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
Hi! > > But here's what I've got: > > > > [EMAIL PROTECTED]:/home/pavel# fsck.ext2 -f /dev/hda3 > > e2fsck 1.38 (30-Jun-2005) > > Pass 1: Checking inodes, blocks, and sizes > > Inode 371989 has illegal block(s). Clear? yes > > > > Illegal block #2 (134217728) in inode 371989. CLEARED. > > Pass 2: Checking directory structure > > > > i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072, > > should be zero. > > Clear? yes > > > > Pass 3: Checking directory connectivity > > Pass 4: Checking reference counts > > Pass 5: Checking group summary information > > Block bitmap differences: -339972 +471044 > > Fix? yes > > > > Free blocks count wrong for group #10 (13882, counted=13883). > > Fix? yes > > > > ...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- > > I was > > using it till crash for half a year, but that's what journal is for, > > right? ...But I guess this is almost impossible to debug? > Actually, your case doesn't seem to be hard. The first block number > is 0x800 and the second one 0x2. So something is flipping your > bits... Hmm, ouch. Yes, that machine was pretty unstable after repeated suspend-to-RAMs, so I guess this is a symptom of same problem. Sorry about noise. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
Hello, > But here's what I've got: > > [EMAIL PROTECTED]:/home/pavel# fsck.ext2 -f /dev/hda3 > e2fsck 1.38 (30-Jun-2005) > Pass 1: Checking inodes, blocks, and sizes > Inode 371989 has illegal block(s). Clear? yes > > Illegal block #2 (134217728) in inode 371989. CLEARED. > Pass 2: Checking directory structure > > i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072, > should be zero. > Clear? yes > > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > Block bitmap differences: -339972 +471044 > Fix? yes > > Free blocks count wrong for group #10 (13882, counted=13883). > Fix? yes > > ...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I > was > using it till crash for half a year, but that's what journal is for, > right? ...But I guess this is almost impossible to debug? Actually, your case doesn't seem to be hard. The first block number is 0x800 and the second one 0x2. So something is flipping your bits... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
Hi! > > > #1, This is why periodic checks are a good thing; it catches problems > > > that could stay hidden and result in data loss sooner rather later. > > > > Actually, I see something funny with periodic checks here. It claims > > 'filesystem check on next boot' for >10 boots now. > > > > It is sharp zaurus machine, and the filesystem tends to _never_ be > > unmounted correctly (broken scripts), so I get journal replay each > > time. > > The Sharp Zaurus is a PDA which is almost always running on battery, > right? You need to add to /etc/e2fsck.conf: Right. Could we get more helpful message here? 'Filesystem check on next boot on AC power'? Or maybe keep counting, and when we reach 2x mount-count-limit, force a fsck, battery power or not? > [options] > defer_check_on_battery = false I guess openembedded people should make this default on zauruses... > power. But for a PDA running a flash drive which is almost always > running on battery you'll want to change the default using > e2fsck.conf. I'll just remember to do it manually, I guess. But here's what I've got: [EMAIL PROTECTED]:/home/pavel# fsck.ext2 -f /dev/hda3 e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Inode 371989 has illegal block(s). Clear? yes Illegal block #2 (134217728) in inode 371989. CLEARED. Pass 2: Checking directory structure i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072, should be zero. Clear? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -339972 +471044 Fix? yes Free blocks count wrong for group #10 (13882, counted=13883). Fix? yes ...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I was using it till crash for half a year, but that's what journal is for, right? ...But I guess this is almost impossible to debug? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Sun, May 20, 2007 at 07:55:26PM +, Pavel Machek wrote: > > #1, This is why periodic checks are a good thing; it catches problems > > that could stay hidden and result in data loss sooner rather later. > > Actually, I see something funny with periodic checks here. It claims > 'filesystem check on next boot' for >10 boots now. > > It is sharp zaurus machine, and the filesystem tends to _never_ be > unmounted correctly (broken scripts), so I get journal replay each > time. The Sharp Zaurus is a PDA which is almost always running on battery, right? You need to add to /etc/e2fsck.conf: [options] defer_check_on_battery = false See the e2fsck.conf man page for more details, but basically, e2fsck was optimized for x86 laptops that have such lousy batttery life that people generally try to run AC adapters to avoid killing the laptop battery --- and for which running a spinning hard drive platters for an extended time to fsck a 100GB drive might not be such a hot idea. So we try to defer the periodic fsck until the laptop is back on AC power. But for a PDA running a flash drive which is almost always running on battery you'll want to change the default using e2fsck.conf. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
Hi! > > > How do you know that the corruption was caused by 2.6.21-rc1 ? > > > Isn't it possible that the corruption was created by an earlier > > > kernel, but only detected when a forced fsck was run - which just > > > happened to be while you were running 2.6.21-rc1 ... > > > > > > My point is that, as far as I can see, there's nothing tying > > > 2.6.21-rc1 specifically to this corruption... or? > > > > You might be right, but I thought maybe more probably is the cause in kernel > > as that is what I have changed recently. ;) Or maybe someone can at leats > > say > > "No, no changes to be considered between 2.6.20.6 and 2.6.22-rc1.". ;) > > Well, given that your e2fsck transcript started with this: > > > /dev/hda3 has been mounted 38 times without being checked, check forced > > #1, This is why periodic checks are a good thing; it catches problems > that could stay hidden and result in data loss sooner rather later. Actually, I see something funny with periodic checks here. It claims 'filesystem check on next boot' for >10 boots now. It is sharp zaurus machine, and the filesystem tends to _never_ be unmounted correctly (broken scripts), so I get journal replay each time. Anyone else sees that? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
