> The issue was about adding extra streams to a file in a way which does
> not change the visible contents of the file as seen by a normal open().
> It's not an issue of keeping the "main" contents of the file in a
> subfork; it's a question of adding subforks _without_ disturbing the
> main contents. That, by definition, changes the semantics of namei():
> you no longer get the whole contents of the file back when you do an
> open() and read().
>
> That is the crux of my objections. If we add such hidden information,
> then all our current tools (NFS, tar, cp, mv etc) fail. NFS in
> particular is a killer: by adding functionality to the fs which cannot
> be encoded in the standard NFS protocol, we lose the ability to share
> these files.
This seems to decide the issue right here: any solution based on ReiserFS,
or an expanded ext2fs, would be intrinsically unportable. Such techniques
could be used, but only as a Linux-local optimization. Otherwise, we kill
portability and transportability, which contradicts the entire point of
the game.
> If we want to add tagged information to a file, far better to do it via
> a dot directory. Keep the problem in user space where it belongs. Any
> extra efficiency that the fs has to offer will still be realised by such
> a mechanism.
Agreed -- though it might make sense to treat dot directories as just one
implementation of metadata, with others possibly available -- and some
standard library and flat-format to make this stuff portable.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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.altern.org/andrebalsa/doc/lkml-faq.html