lkml.org 
[lkml]   [1998]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Implementing Meta File information in Linux (and a note at the end on current reiserfs status)
Brandon S. Allbery writes:
> One thought I had was that read() on a file with metadata returns a
> structured file containing all the data and metadata *unless* the program
> issues an fcntl() to switch to metadata mode. (Note that metadata/"forks"
> and databases are not disjoint --- Mac System 6 and later, IIRC, use a btree
> for the resource fork.) Having done that, read() returns only normal data
> and other fcntl() operations are used to access metadata.
>
> If you hide the fcntl()s and metadata-aware read() inside other functions,
> you also get an API which could be implemented as a library on systems
> lacking metadata (the physical disk file actually is the above structured
> file) --- and to provide cross-platform metadata routines for Mac, NTFS,
> OS/2, etc. Of course, at this point the claim could be made that one
> doesn't need the fcntl() stuff, just the library (but! it will perform
> horribly unless the "structured file" is really a file and a backing (e.g.)
> reiserfs directory --- in which case you can lose by not realing that you
> need to copy the directory as well as the file.

Can you explain why you think that keeping the metadata in a normal
file and splitting the data streams in userspace is going to be slow?
I would have expected the file would have a "header" which describes a
series of data streams, including file offsets. Putting the non-data
metadata at the front would allow the normal data component to grow
without any problems. Even if more metadata was added later, it would
likely be small, so it could be easily cached and appended as the
normal data grew. Accessing a particular stream is just a seek
operation.
Of course, if you have large metadata, then you're better off making
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 streams
(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.

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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.100 / U:4.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site