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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Jan 2020 23:09:03 +0000 From: David Howells <dhowells@...hat.com> To: Andreas Dilger <adilger@...ger.ca> Cc: dhowells@...hat.com, Christoph Hellwig <hch@....de>, Qu Wenruo <quwenruo.btrfs@....com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk>, "Theodore Y. Ts'o" <tytso@....edu>, "Darrick J. Wong" <darrick.wong@...cle.com>, Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, linux-ext4 <linux-ext4@...r.kernel.org>, linux-xfs <linux-xfs@...r.kernel.org>, linux-btrfs <linux-btrfs@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: Problems with determining data presence by examining extents? Andreas Dilger <adilger@...ger.ca> wrote: > > It would also have to say that blocks of zeros shouldn't be optimised away. > > I don't necessarily see that as a requirement, so long as the filesystem > stores a "block" at that offset, but it could dedupe all zero-filled blocks > to the same "zero block". That still allows saving storage space, while > keeping the semantics of "this block was written into the file" rather than > "there is a hole at this offset". Yeah, that's more what I was thinking of. Provided I can find out that something is present, it should be fine. David
Powered by blists - more mailing lists