http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #135 from Eric Sandeen <sandeen@xxxxxxxxxx> 2009-10-27 21:42:09 --- (In reply to comment #134) > Example issues that are exclusive to the root filesystem and would never > be an issue on any other filesystem (exactly due to the "mount ro first, > fsck later" behavior of root): > > - flaky in-kernel recovery code might trash more than it fixes, and would > never trigger for the "fsck first" case because fsck would already have > done it. Yep, but I didn't have auto-fsck in my non-root testing, and I did "mount -o ro" followed by "e2fsck -a" on it to try to "be like /", and didn't see it. Though I'll re-check just to be sure. > - flaky user-mode fsck doesn't understand that the kernel already did > recovery, and re-does it. It should print out a message if it's recovering again, we should see it in the logs... and I don't think I have. > - virtually indexed caches might be loaded by the mount, and when you do > fsck later, the fsck writes back through the physically indexed direct > device. So the mounted root filesystem may never see those changes, > even after you re-mount it 'rw'. Yes, I've been worried about this... but would this be new? Could probably test this theory by forcing an immediate reboot if e2fsck does recovery on a readonly mounted fs. > - even if every filesystem cache is physically indexed (ie using the > buffer cache rather page cache), there may be various cached values > that the kernel keeps around in separate caches, like the superblock > compatibility bits, free block counts, etc. fsck might change them, but > does 'remount,rw' always re-read them? same test above would help determine this, I think. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
