On Wed, Jul 28, 1999 at 02:02:43PM -0400, Alexander Viro wrote:
> >Are we off-topic yet?
> Sure we are ;-) But... why not? ObNTFS: I've looked into that stuff and
> I have pre-alpha code doing indirect blocks in page cache for ext2.
Presumably it does give a performance improvement over the buffer cache,
or you wouldn't be doing it ;-)
> The same technics can be applied to NTFS forks.
I'm not sure it can, easily. Even if we don't allow applications to create
arbitrary forks (and I've no intention of allowing them to do that),
inodes can have a number of different forks other than the data fork, and
they can be arbitrarily long. Let me dig out my list... Here we go:
$STANDARD_INFORMATION:
okay, this is a fixed small size, no problem -- and it's also always
'resident' inside the FILE structure (on-disk inode), so won't end up
in the page cache anyway.
$FILE_NAME:
this has a max size of about 544 bytes, but there can multiple
instances (to handle hard links -- yes, NTFS keeps the file
names for a file in the inode _and_ in the directory. *sigh*); it's
always resident as well, though, so not a problem.
$SECURITY_DESCRIPTOR:
an ACL, basically. AFAIK it can be arbitrarily large, but whether
it can grow depends on whether we added ACL support to the Linux
driver.
$DATA:
actual file contents. not present for directories.
$INDEX_ROOT:
root node of the b+ tree of directory entries. Always resident.
$INDEX_ALLOCATION:
this contains all the sub-nodes of the b+ tree for directories.
Always non-resident (i.e., a problem ;-), and can grow.
$BITMAP:
this is used to mark blocks in $INDEX_ALLOCATION as in-use or free.
Presumably it can be non-resident, and can grow (as $INDEX_ALLOCATION
grows).
So files are OK: $DATA is the normal file data stream, and can we store the
security descriptor using negative offsets.
Directories: we can stick INDEX_ALLOCATION in the page cache as normal (+ve
offsets), but we've got to deal with BITMAP and SECURITY_DESCRIPTOR, both
of which can grow, so I don't think we can (sanely) store both of those using
-ve offsets, can we?
The other solution is to add a field to struct page - I doubt it needs to
be hashed - which could be used to specify which fork the data belonged to,
or for any meta-data you want to stick in the page cache for ext2. The problem
is the effect this has on performance. __find_page has:
...
page = page->next_hash;
inside:
if (!page)
goto not_found;
if (page->inode != inode)
continue;
if (page->offset == offset)
break;
...
which would have to become
...
if (!page)
goto not_found;
if (page->inode != inode)
continue;
if (page->offset != offset)
continue;
if (page->stream == stream)
break;
...
I'm not experienced enough to know what sort of a hit we'd take from doing
this, and whether it's acceptable or not.
> BTW, another trick in the same patch (also from BSD) being that
> it keeps the position of last ->lookup() (reset by modifications and
> negative lookups) in the in-core inode of directory. It works for VFAT
> (in 2.2.11-pre2 and -ac) and IMO it got enough beating to try it with the
> main filesystems. Is there any natural search order on NTFS directories?
> We could do the same there...
Err.. My brain hurts ;-) NTFS uses some sort of binary tree, so I don't
think it can be done easily: nodes don't store references to their parent,
so you'd have to store a reference to all the ancestors to the current node
to be able to pick up the search, and you could be at any depth in the tree.
It all depends how much of the tree gets kept in memory, I guess. (BTW,
does ext2 use the buffer cache or the page cache for directory contents?)
I was following the vfat argument^Wdebate with trepidation: I guess we have
the same problem with NTFS: a file can have multiple names in a single
directory. There's a 'namespace' bitmap for each filename (0=POSIX namespace,
1=Win32 namespace, 2=DOS namespace, 3=Win32+DOS namespace). Having said that,
I think there's an (undocumented) option for WinNT's NTFS driver to stop
it generating backward combatible DOS names, so maybe that means WinNT doesn't
do horridness like storing the DOS names instead of the Win32 names. God
knows what happens to 16 bit apps in that situation, though.
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
Yes, I got into work one morning last year and found that cartoon taped to my
monitor (I can't imagine why..)
Hope some of the above makes sense, I'm expecting a clue-by-four by return of
post for the page cache suggestion ;-(
--
"House Plants are for ornamental use only and not for consumption"
Notice in Sainsbury's Supermarket, London - Daily Mail
