Messages in this thread | | | Date | Fri, 4 Sep 1998 17:43:26 +1000 | From | Richard Gooch <> | Subject | Re: (reiserfs) Re: Implementing Meta File information in Linux (and a note at the end on current reiserfs status) |
| |
H. Peter Anvin writes: > Followup to: <199809031247.WAA16479@vindaloo.atnf.CSIRO.AU> > By author: Richard Gooch <rgooch@atnf.csiro.au> > In newsgroup: linux.dev.kernel > >=20 > > > > Of course, if you have large metadata, then you're better off makin= > g > > > > each stream as a file in a directory and letting the FS do the work. > > > > The FS code already has one bunch of code to implement growing stre= > ams > > > > (files), I think we'd want to leverage that instead of implementing > > > > yet another level of what is effectively file/directory management > > > > inside the FS. > >=20 > > To clarify: I see two situations. The first is where you have a small > > number of secondary streams of small size which don't grow much. Here > > a single file can suffice. > > The second case is where these assumptions break down, and in that > > case I think each stream belongs in a file. A userspace API is written > > to allow you to deal with the dataset as a single object. For > > consistency, even where the above assumptions hold, it's probably > > better to use one file per stream. > > I see directories being excellent placeholders for grouping > > metadata. With reiserFS, this userspace implementation will be very > > fast, so it's the logical way to go, IMO. > >=20 > > For the small data objects (i.e. "resources"), it seems that using a > standard database library like gdbm or db is appropriate.
Except (see my earlier post) that keeping things in a separate catalogue also has it's problems. It makes it impossible to use standard tools to move/backup a file with all it's metadata. A sysadmin also has to know the specialised tools to deal with the metadata. That's why I think the data and metadata should be kept in the one place: either all in one file or using a directory.
Anyway, I see all of this as a userspace problem.
Regards,
Richard....
- 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/faq.html
| |