Ingo,
> You can use (GNU-)tar for this. It even keeps track of other bits like
> ext2fs attributes, AFAIK.
True..., but cramfs is acting like a mountable (tar czvf) because of the
compressed pages. Seems redundant to have a tar on top of what is basically
a segmented tar with frontal indexing (read inodes).
> > On the other hand..., maybe I'm being "selfish", and this is the right
> > way to go. You never write to it, so why track the write bits?
>
> Yes, I would consider this "selfish" ;-)
Maybe :), that's why I mentioned it.
> > (One answer is maybe later we can create a writable cramfs, but
> > oh well)
>
> This could then be solved with union mount and cramfs mount over
> ramfs or any other writable Unix style fs.
>
> Then we might need W bits, but currently they disturb things like
> "test" and the perl equivalent, which is quite annoying and
> complexifies code. (Yes, I'm selfish too ;-))
Simplifying code is a good objective..., but we've already got the bits
there, and actually when you look at the patch it's adding complexity, not
subtracting from it. (Adding additional operations on the fetch of every
inode..., plus wholesale stealing bits from operational mode of a filesystem,
but the bits are useless in the "normal interpretation" of it, so I see your
point) I guess the part that bugs me is you make a filesystem out of a
directory sub-structure expecting a 1-1 relationship of the data in the
original directory sub-strucure, and the interpretation of your cramfs
filesystem. But then you pull out the write bits, and that 1-1 relationship
is gone. (I can only see my particular case, but there are probably others
this disturbs)
Thanks,
Shane Nay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
