On Fri, 8 Jun 2001, Alexey Zhuravlev wrote:
> AV> How about "lots of filesystems that exepct BKL to be there when
> AV> directory methods are called"?
>
> 1) there is down(...). Not enough?
Not really. It gives you exclusion between operations on that directory,
It's neither stronger nor weaker than BKL.
> 2) why do not let fs to make it inside lookup method? It's simple, imho
Sure, it is. However, that's not a good idea during 2.4 - API changes are
better left for 2.5, unless there is a really strong reason to do them in
stable branch.
> For some application it's really bottleneck, imho. And next question:
> why do not use rwsem for VFS?
Sigh... Look: we have a bunch of filesystems. They have their own data
structures. To change exclusion rules we must make sure that it will not
break this internal stuff. IOW, every time we do such changes, we must
check all filesystems. On the level of private mechanisms they use.
It _is_ doable. Been there, done that. But that's -CURRENT stuff, not
-STABLE.
As for the rwsem... If you mean ->i_sem - it's more or less OK on the VFS
side, except that we'll need to deal with parallel lookups on the same name.
It can be dealt with, but I'm not sure that it will give any visible benefits.
On the fs side... UNIX-style filesystems will be OK with it. msdosfs is
_probably_ OK as long as you give it exclusion between lookups on the same
name. VFAT is going to be a mess, though - handling aliases is not fun as
it is and that will make it worse. HPFS has a locking of its own and you'll
need to check that it doesn't rely on the exclusion you want to remove. NTFS -
no idea whatsoever. NFS - same issue as with msdosfs. Other than that it's
probably OK. ISOFS - probably OK, but you'll need to RTFS to make sure.
HFS - my gut feeling is that it will be messy and subtle, but I can be wrong
(it plays interesting games with HFS forks, and that may be a problem).
AFFS - hell knows. SMBFS and NCPFS - same issue as with NFS. procfs -
very likely to be a problem in per-process part, more or less innocent in
the rest. romfs and QNX4 - same as UNIX filesystems. autofs and devfs - may
be a problem, you'll need to look into the detail of protocols used for
talking with their userland parts. CODA - aside of the same issue as with
NFS, probably OK. ADFS - no idea. EFS - probably OK. cramfs - may be a problem,
but I hadn't looked into the handling of directories there. If anything like
directory compression is used - expect some pain. usbdevfs and capifs -
nasty, but probably fixable. Internal structures are not too pretty there.
IOW, it will take a nontrivial amount of work and all you win is ability
of parallel lookups. Notice that it means a heavy burst of lookups in
the same directory, all from different processes and none of them hitting
dcache (we go to filesystem code only in case of dcache miss).
I doubt that it will be a bottleneck. Look at it that way: we need to get
directory in core and we need to search in it. In the situation above (burst
of dcache-missing lookups) you are _very_ likely to need IO to bring the
data in core. It means that the first lookup will start the IO and the
rest will block on it. I.e. you will get parallel execution only on the
search phase, which is much faster than physical IO. So _if_ you had a
bottleneck in real_lookup() you are very likely to get it back in the
foofs_lookup() on bread()/read_cache_page()/whatever you use for IO.
I can be wrong on it - it is certainly possible to construct a scenario
when bottleneck is there and gets removed by such change.
It may be a valid project for 2.5, but I'm not sure that it's worth the
trouble. It will give you more experience with weird code than you ever
wanted and may uncover existing races. So if you want to do it - go ahead,
start checking fs internals.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
