implementing soft-updates
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Dominik Kubla
The background fsck capability, just like journalling or logging, are typically only in needed in 24/7 systems (sure, they are nice to have in your home system, but do you _REALLY_ need them? i don't!) and those system typically are run on proven hardware which is operated well within the specs. So please don't construct these kinds of arguments.
You can already do background fsck on a linux system today. Just do it on a LVM/EVMS snapshot.
-Andi
Hi
Quoted 8 lines
Quoted 5 lines
The background fsck capability, just like journalling or logging, are typically only in needed in 24/7 systems (sure, they are nice to have in your home system, but do you _REALLY_ need them? i don't!) and those system typically are run on proven hardware which is operated well within the specs. So please don't construct these kinds of arguments.
You can already do background fsck on a linux system today. Just do it on a LVM/EVMS snapshot.
How do you fix errors you find by such background fsck?
Pavel
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 8 lines · Pavel Machek
Hi
Quoted 6 lines
Quoted 5 lines
The background fsck capability, just like journalling or logging, are typically only in needed in 24/7 systems (sure, they are nice to have in your home system, but do you _REALLY_ need them? i don't!) and those system typically are run on proven hardware which is operated well within the specs. So please don't construct these kinds of arguments.
Quoted 4 lines
Quoted 2 lines
You can already do background fsck on a linux system today. Just do it on a LVM/EVMS snapshot.
How do you fix errors you find by such background fsck?
You umount the file system (that is the best you can do with a random error anyways, BSD doesn't do any better except in the special case of lost blocks in the bitmap) and fsck it again on the real volume.
In theory you could build a mechanism to pass some state from the first fsck to the second to speed the second up, but it is probably not worth it.
-Andi
Quoted 5 lines · Pavel Machek
Quoted 2 lines · Andi Kleen
You can already do background fsck on a linux system today. Just do it on a LVM/EVMS snapshot.
How do you fix errors you find by such background fsck?
You shouldn't get any in the first place (they would be from disk errors, memory corruption, software bugs, etc). If you _do_ get such an error, isn't it worth it to shut down your system and bring it back to a known state (and maybe figure out what actually caused this error)?
The only reason to have such a feature is for high-availability, high-uptime systems which cannot normally be shut down. In very recent versions of e2fsprogs, you are able to reset the "last checked" field in the superblock (you could reset the "mount count" field for a long time), so that you do an online check every week/month, then you can avoid the forced fsck after a reboot because the filesystem hasn't been checked in 6 months.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
In article <[email protected]>,
Quoted 1 line · Pavel Machek
How do you fix errors you find by such background fsck?
Theoretically I suppose you could use a writeable snapshot and then switch the fscked snapshot with the currently mounted fs.
Wichert.
Signature · 4 lines
_________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | [email protected] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Quoted 7 lines · Wichert Akkerman
In article <[email protected]>,
Quoted 1 line · Pavel Machek
How do you fix errors you find by such background fsck?
Theoretically I suppose you could use a writeable snapshot and then switch the fscked snapshot with the currently mounted fs.
Not if there were writes after the fsck. You could probably do it if there were only reads though. If there were writes it would be based on a corrupted (to whatever extent) filesystem.