linux-ext4 - Re: Enabling h-trees too early?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2007 07:45:04 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: Enabling h-trees too early?

On Fri, Sep 21, 2007 at 11:02:58AM +0200, Andi Kleen wrote:
> I assume you mean sort by inode, because sort by htree key would
> be as bad as htrees.
> 
> But wouldn't that break parallel readdir for a directory that just grows
> from <32/64K to over it?  e.g. if the sort moves already read 
> entries to after the  cursor readdir would return some entries twice.

No, it wouldn't break it because after snapshotting the tree, we would
only use the snapshot and not refer to the on-disk format until the
directory file handle is closed or there is an explicit lseek to 0.
To quote from the spec:

  If a file is removed from or added to the directory after the most recent
  call to the opendir() or rewinddir() function, whether a subsequent call to
  the readdir() function returns an entry for that file is unspecified.

So, if some program does the stupid thing and opens a directory,
doesn't use it for five hours, and in the meantime 2,000 files are
created, it's OK if we only return the set of files that were in
existence when the opendir() was originally called.  This makes us OK
in terms of spec conformance, and given that real life programs don't
do stuff this stupid, we should be fine.

					- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html