As I see, the problem of 'albods' is unclear for many of us.
Let me to formulate it.
1. What for?
- ACLs
- file types
- dynamic common part of some files
- file comments
- effective configuration storage
etc.
Many existing programs already use fake metadata!!!
2. Why in the kernel?
a. *Huge* perfomance losses (10 - 1000%)
For example to determine type of all files in a directory
file managers must:
- refer to file extensions (this is wrong - we are not in DOS)
- refer to /etc/magic (very slow)
- create cache database (it will duplicate file names
=> waste disk space)
Another example is parsing conf files:
Slower than damned M$ registry!!! Unacceptable.
Or may be you'll suggest to port registry to UNIX? :-(
b. Security holes
ACLs in tarball?
3. What is the problem?
While new programs will correctly work with metadata,
Old programs may be broken.
So, the problems is how old programs will see forked files.
4. Possible variants (all):
'clear' ideas:
- old programs see forked files as directories
mailer will not be able to attach such file
- old programs see forked files as tarballs
grep /forked_files/* - will fail
- old programs see forked files as default data
mv will destroy all other forks
- old programs will not get access to the forked files
they will not be happy
inherited ideas:
- regluar (wrong) access to the forked files
will cause a daemon notification
- combine ideas
for example, critical forks stored in tarball,
but non-critical forks are invisible for old apps.
+daemon notification
5. As you see, in any case, some old applications will be broken.
But if the problem will be ignored - new applications will be slow.
(they are already too slow)
=> In any case somebody will not be happy.
Personally I suggest to choose a variant with minimal compatibility affects
ASAP.
Best regards
Alexander
-
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/