Re: New FS with search properties
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 05/27/04
- Next message: Kasper Dupont: "Re: Q:malloc"
- Previous message: Lew Pitcher: "Re: Login application"
- In reply to: Uddo Graaf: "New FS with search properties"
- Next in thread: Clint Byrum: "Re: New FS with search properties"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 27 May 2004 16:45:30 +0200
Uddo Graaf wrote:
>
> I'm not sure if the authors of any filesystems are present in this NG but I
> would like to suggest a new feature to combat WinFS. Why not allow
> properties to be added to any file, of any length and or type. This way, we
> other programs could be used to search the filesystem in a database like
> manner.
>
> For example, an indexing property would be used to index the disk files and
> maybe even its contents.
>
> What do you guys think?
I think some filesystems already have support for that.
Though the extra properties cannot be added by an
arbitrary program, they have to be added by kernel code.
ISO9660 was designed to be extended, rockridge is one
example of such an extension.
I'm almost sure ext3 also is designed for such extensions,
and it is already used for some kind of ACL.
And I think (but I'm very unsure about this), that
reiserfs allows some extensions as well.
So I think most of the infrastructure is in place, what
is missing for your idea to be realized is:
1) Find out exactly what kind of data you want to allow
applications to attach to the files.
2) Define the required system calls to get/set these
attributes, and think very carefully about the
security.
3) Define a way to store the information in iso9660,
ext3, and reiserfs, such that it does not interfere
with other extensions.
4) Rewrite mkisofs (and friends) to read the attributes
and write them into the iso9660 image.
5) Rewrite all copy and backup utilities to know about
the attributes and store/restore them as well. That
also means you need to extend the storage formats.
Of course you can take a completely different approach.
Instead of relying on the kernel to take part in the
job, just do it all in user code. Create a few files
to store the meta data. Depending on your goal, these
can be stored in /var, in the root of each filesystem,
in each directory, or in the home directory of each
user.
Of course without filesystem/kernel help you have a
great deal of trouble keeping the two in sync. The meta
file doesn't get updated when a file is created, renamed,
moved, linked, or deleted.
You could even try to come up with a hybrid, where the
extra metadata file is visible to all applications that
doesn't know anything about the new API, including the
usual backup utilities.
Care must be taken to ensure that a restore utility
writing the metadata file produce the expected result.
I think you should try to explain in details how you
would design it. Give a short explanation of why it is
a good idea. And give a detailed explanation of why you
think your system will not introduce any new problems.
-- Kasper Dupont -- der bruger for meget tid paa usenet. For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk I'd rather be a hammer than a nail.
- Next message: Kasper Dupont: "Re: Q:malloc"
- Previous message: Lew Pitcher: "Re: Login application"
- In reply to: Uddo Graaf: "New FS with search properties"
- Next in thread: Clint Byrum: "Re: New FS with search properties"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
