Re: info about filesystem errors in /sys/fs/ext4/... ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



For the record, since this was discussed on the ext4 weekly
teleconference...

The reason why I've been hesitant about allowing any file system to be
checked by e2fsck while being mounted read-only is because of the
following failure scenario:

1) The kernel discovers that a file system has been corrupted, so it
marks the file system as being inconsistent and it remounts the file
system read-only.

2) The user runs e2fsck on the file system, while it is still mounted
read-only, and fixes it.

3) The kernel still has cached data structures with incorrect inode
reference counts, etc.  So when the user then remounts the file system
read/write, the file system gets corrupted again, and the user suffers
data loss.


This could happen with the root file system as well, of course, but
there is a big, large, scary message making it clear that you *MUST*
reboot after repairing a corrupted root file system.  The real issue
is encouraging users from checking mounted file systems at all.  One
approach would be do to require a command-line option of the form
--i-know-this-is-dangerous-and-I-could-lose-data, or some such.
Apparently xfs does something like this, with a xfs_repair -d ('D' is
for Dangerous).

Another approach which Andreas Dilger suggested, and which we will
likely use, is one where we snapshot the last fsck time from the
superblock when the file system is mounted or remounted read-only.
Then when the user tries to remount the file system read-write, if the
last fsck time has been changed, we reject the r/w remount request.

Regards,

						- Ted
--
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




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux