Messages in this thread | | | From | David Lang <> | Date | Thu, 26 Aug 2004 14:17:46 -0700 (PDT) | Subject | Re: silent semantic changes with reiser4 |
| |
On Thu, 26 Aug 2004, David Masover wrote:
> Christophe Saout wrote: > > | Yes, the main compound stream unaware applications would see would just > | be a writable view of its contents. Probably not trivial to implement > | but doable. > > Not the main stream, I think, but we do need a way to make "eight-stream > octopus" files portable. But there needs to be a copy(2) syscall, and > apps need to start supporting it. After all, copy-on-write was planned > for Reiser4, now 4.1*. And don't anyone dare suggest "userland library". > > | It should be a simple format. Something simliar to tar. The worst thing > > Simple, yes. Similar to tar, no. > > How about a serializer plugin? foo.mp3/serialize (say) should return > some single stream which contains all of foo.mp3. It could work for > directories as well, recursively, at least on the same filesystem -- > you'd back up by doing > > cp /serialize /backup/20040826 > > This has two potential problems. One is security -- I want to be able > to serialize foo.mp3 without being root, but root doesn't want me to be > able to serialize /etc and thus get access to shadow. > > The second problem is that in order to actually be used for backup, we > need snapshots, which are not done yet*. Currently, it'd have to lock > the file/directory (recursively), which you don't want to do to entire > live filesystems... So, no massive backups of live systems yet, but > definitely useful for sending around mp3s and such. > > | that can happen is people start writing plugins for every existing > | compound format out there. It should be the other way around, agree on a > | simple compound format and encourage applications to use this one if the > | want to use this advantage. > > For the format, I vote for whatever format we're using at the storage > layer. It'd be a lot faster that way, both in execution time (I think) > and in development time (I'm sure). Plus, imagine the restore: > > cat /backup/20040826 > /dev/hda5 > resizefs_reiser4 /dev/hda5 >
one of the virtual metatags should be something about the method to serialize the data
if you are viewing a tarfile as a directory the VFS/Filesystem shoud know that the link between the whole thing and the contents is tar, and it should be possible for userspace programs to find this out by reading teh appropriate thing inside the virtual directory (and eventually change it as well, which would trigger regeneration of the base object, or at least noting that the current version is wrong and needs to be regenerated)
David Lang
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |