>> No, not like that at all. Structured storage adds an extra allocation
>> and namespace layer above the filesystem. This works in userspace,
>> but the performance is poor.
> I'm not convinced this has to be the case (that performance will be
> poor).
For now, every app with this problem has to implement something like
a growable (and hopefully shrinkable) filesystem within a file.
Apps can add a block mapping layer complete with triple-indirect
blocks, or they can copy around huge amounts of data and update
document references as needed.
>> You can get the performance today by using directories, but that
>> destroys usability. Documents need to appear as files to the user,
>> so they must appear as files to traditional POSIX software.
>> It isn't enough to patch a file manager. You'd have to bloat
>> everything in the whole system, perhaps losing the performance!
>
> That's why I suggested using a user-mode libc hack in cases where the
I greatly dislike playing with libc. There once was a libc that
would do compression, but it is dead now.
Static executables are a problem.
Every stat() call that acts on a directory must cause guessing,
perhaps by doing many more system calls inside the directory.
I doubt this would help with web benchmarks -- it will be disabled.
Without kernel support, the library would have to guess which directories
need special treatment. This is a bug unless you can explain how various
standards let directories suddenly and accidentally turn into files.
At the very least this is ugly behavior.
I hate to see libc full of heavy wrappers. Many filesystem functions
would have to do several additional system calls. Eew.
> should be just as performant as your NTFS "reparse point" approach ---
> with the added advantage that I don't have to implement "tar" in the
> kernel, which the "reparse point" approach requires. (OK, it's a
> loadable kernel module --- but it's still implementing "tar" in the
Note that we do have an NTFS driver. This driver is clearly missing
support for reparse points. Do you have a solution for that?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/