Re: forced fsck (again?)

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

 



Valerie Henson wrote:
...
This will be ironic coming from me, but I think the ext3 defaults for
forcing a file system check are a little too conservative for many
modern use cases.  The two cases I have in mind in particular are:

* Servers with long uptimes that need very low data unavailability
times.  Imagine you have a machine room full of servers that have all
been up and running happily for more than 180 days - the preferred
case.  Now imagine that the room overheats and the emergency power cut
is tripped.  Standard heat reduction is swiftly applied (i.e., open
the door and turn on a fan and hope security doesn't notice) and the
power turned back on.  Now your entire machine room will be fscking
for the next 3 hours and whatever service they provide will be
completely unavailable.  Of course, any admin worth their salt will
turn off force fsck so it only runs during controlled downtime...
won't they?

Agreed. This is a real problem. And controlled downtime is rather difficult if it takes several hours to complete. You're either without whatever services they provide or with reduced redundancy for that time.

* Laptops.  If suspend and resume doesn't work on your laptop, you'll
be rebooting (and remounting) a lot, perhaps several times a day.  The
preferred solution is to get Matthew Garrett to fix your laptop, but
if you can't, fscking every 10-30 days seems a little excessive.
Desktop users who shutdown daily to save power will have similar
problems.  Distros often have the "don't fsck on battery" option and
some don't use the ext3 defaults for mkfs, but that's only a partial
solution.  In this case, it's definitely a little much to ask a random
laptop user to tune their file system.

Agreed again. Having a laptop insist on an fsck when about to give a presentation to a room full of professors is really not a good look. And being flimsier and more abused than desktops, laptops IMO really do need regular checking.

I'm not sure what the best solution is ...

I am.

Since fscks are unacceptably inconvenient and apparently the only thing worse than enforcing periodic fscks is *not* enforcing periodic fscks, then we only have one option. Make fscks less inconvenient. And since we apparently can't make them any faster, the only way I can think of to do that is to add support for (you know what I'm going to say):

Online fscks.

We really, *really* need to support checking of mounted read/write file systems. I would envisage a read-only fsck done on all mounted filesystems regularly, which wouldn't do any damage to a file system if implemented properly. If an inconsistency is picked up, then recommend an offline one to be scheduled when the user/admin is ready.

Greg


_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux