| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <60808.198.182.194.170.1199827911.squirrel@clueserver.org> Date: Tue, 8 Jan 2008 13:31:51 -0800 (PST) From: "Alan" <alan@...eserver.org> To: "Al Boldi" <a1426z@...ab.com> Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFD] Incremental fsck > Andi Kleen wrote: >> Theodore Tso <tytso@....edu> writes: >> > Now, there are good reasons for doing periodic checks every N mounts >> > and after M months. And it has to do with PC class hardware. (Ted's >> > aphorism: "PC class hardware is cr*p"). >> >> If these reasons are good ones (some skepticism here) then the correct >> way to really handle this would be to do regular background scrubbing >> during runtime; ideally with metadata checksums so that you can actually >> detect all corruption. >> >> But since fsck is so slow and disks are so big this whole thing >> is a ticking time bomb now. e.g. it is not uncommon to require tens >> of minutes or even hours of fsck time and some server that reboots >> only every few months will eat that when it happens to reboot. >> This means you get a quite long downtime. > > Has there been some thought about an incremental fsck? Is that anything like a cluster fsck? ]:> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists