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
| ||
|
Date: Tue, 01 Aug 2006 10:24:49 +0300 From: Avi Kivity <avi@...o.co.il> To: Theodore Tso <tytso@....edu> CC: David Lang <dlang@...italinsight.com>, David Masover <ninja@...phack.com>, tdwebste2@...oo.com, Nate Diller <nate.diller@...il.com>, Adrian Ulrich <reiser4@...nkenlights.ch>, "Horst H. von Brand" <vonbrand@....utfsm.cl>, ipso@...ppymail.ca, reiser@...esys.com, lkml@...productions.com, jeff@...zik.org, linux-kernel@...r.kernel.org, reiserfs-list@...esys.com Subject: Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view"expressed by kernelnewbies.org regarding reiser4 inclusion] Theodore Tso wrote: > > Ah, but as soon as the repacker thread runs continuously, then you > lose all or most of the claimed advantage of "wandering logs". > Specifically, the claim of the "wandering log" is that you don't have > to write your data twice --- once to the log, and once to the final > location on disk (whereas with ext3 you end up having to do double > writes). But if the repacker is running continuously, you end up > doing double writes anyway, as the repacker moves things from a > location that is convenient for the log, to a location which is > efficient for reading. Worse yet, if the repacker is moving disk > blocks or objects which are no longer in cache, it may end up having > to read objects in before writing them to a final location on disk. > So instead of a write-write overhead, you end up with a > write-read-write overhead. > There's no reason to repack *all* of the data. Many workloads write and delete whole files, so file data should be contiguous. The repacker would only need to move metadata and small files. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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