Re: silent semantic changes with reiser4

[Denis Vlasenko]

On Thursday 26 August 2004 22:32, John Stoffel wrote:
> Jamie> Rik van Riel wrote:
> >> And if an unaware application reads the compound file
> >> and then writes it out again, does the filesystem
> >> interpret the contents and create the other streams ?
>
> Jamie> Yes, exactly that.  The streams are created on demand of
> Jamie> course, and by userspace helpers when that's appropriate which
> Jamie> I suspect it almost always is.
>
> So how would a program that converts between a JPEG file (with exif
> data) and a PNG work, such as ImageMagick?  Are we proposing to teach
> the VFS (or worse yet each filesystem) how to do this?
>
> I've been following this discussion a bit and I'm not sure that I've
> actually seen any concrete examples of where this is a *good* thing to
> have.  People talk about only having to modify 20 bytes at a time
> instead of reading and writing 1mb of data.  Isn't that what mmap()
> does?
>
> Now I can sorta understand the idea that having a directory look like
> a file is neat, and certainly simplifies some aspects, but I think
> that going all the way down to the logical conclusion here is a bit
> silly.
>
> To use the principle of blowing things up to make them very large or
> very small, what happens if I decide that the best idea is to make all
> files just be directories which contain single byte files?  Isn't that
> the logical extreme here?  So my 1mb JPEG file is not just some image
> data and header info in multiple files, but it's really just 1
> million (ok 1024 * 1024) individual files that the VFS knows how to
> put together.  Seems like the logical extreme.  Oh wait, maybe we
> should be exposing a single file per bit instead!

It is doable. It doesn't mean we shall do this.

I think some reiser4 supporters try to do too much too soon.
It is more sensible to do it in small steps.

I think we can start small and make all file metadata to be accessible
via file/meta/{uid,gid,mode,mtime,atime,...}.

Normal tools will be unable to see file/meta/ because file is not
a directory and file/ is not a directory (i.e. open(O_DIRECTORY)
will fail on them). Hardlinking to file/meta/* is not allowed.

However, file/. _is_ a directory. We can make a tar-like
tool which can do its work and save/restore metadata along with data
by just tarring/untarring file/meta/*. Notice how this 'new tar'
does not need to know about exact kind of metadata supported by fs.
You can add ACLs to the fs, and this 'new tar' will be able to save/restore
ACLs. Without any modufications.

Contrast this with existing tar which has hardcoded knowlendge about
uid,gid,mode,etc...
--
vda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/