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: Thu, 16 Jan 2020 11:13:44 +0100 From: Christoph Hellwig <hch@....de> To: David Howells <dhowells@...hat.com> Cc: Christoph Hellwig <hch@....de>, Qu Wenruo <quwenruo.btrfs@....com>, Andreas Dilger <adilger@...ger.ca>, 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? On Wed, Jan 15, 2020 at 02:59:38PM +0000, David Howells wrote: > Another thread could be writing to the file at the same time, but not in the > same block. That's managed by netfs, most likely based on the pages and page > flags attached to the netfs inode being cached in this particular file[*]. > > What I was more thinking of is that SEEK_HOLE might run past the block of > interest and into a block that's currently being written and see a partially > written block. But that's not a problem given that you know where to search. > > [*] For AFS, this is only true of regular files; dirs and symlinks are cached > as monoliths and are there entirely or not at all. > > > > However, SEEK_HOLE doesn't help with the issue of the filesystem 'altering' > > > the content of the file by adding or removing blocks of zeros. > > > > As does any other method. If you need that fine grained control you > > need to track the information yourself. > > So, basically, I can't. Okay. I was hoping it might be possible to add an > ioctl or something to tell filesystems not to do that with particular files. File systems usually pad zeroes where they have to, typically for sub-blocksize writes. Disabling this would break data integrity.
Powered by blists - more mailing lists