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, 26 May 2021 01:00:27 +0100 From: David Howells <dhowells@...hat.com> To: Andreas Dilger <adilger@...ger.ca> Cc: dhowells@...hat.com, Theodore Ts'o <tytso@....edu>, "Darrick J. Wong" <djwong@...nel.org>, Chris Mason <clm@...com>, Ext4 Developers List <linux-ext4@...r.kernel.org>, xfs <linux-xfs@...r.kernel.org>, linux-btrfs <linux-btrfs@...r.kernel.org>, linux-cachefs@...hat.com, linux-fsdevel <linux-fsdevel@...r.kernel.org>, NeilBrown <neilb@...e.com> Subject: Re: How capacious and well-indexed are ext4, xfs and btrfs directories? Andreas Dilger <adilger@...ger.ca> wrote: > > Any thoughts on how that might scale? vfs_tmpfile() doesn't appear to > > require the directory inode lock. I presume the directory is required for > > security purposes in addition to being a way to specify the target > > filesystem. > > I don't see how that would help much? When it comes to dealing with a file I don't have cached, I can't probe the cache file to find out whether it has data that I can read until I've opened it (or found out it doesn't exist). When it comes to writing to a new cache file, I can't start writing until the file is created and opened - but this will potentially hold up close, data sync and writes that conflict (and have to implicitly sync). If I can use vfs_tmpfile() to defer synchronous directory accesses, that could be useful. As mentioned, creating a link to a temporary cache file (ie. modifying the directory) could be deferred to a background thread whilst allowing file I/O to progress to the tmpfile. David
Powered by blists - more mailing lists