Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!asstdc.scgt.oz.au!metro!metro!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: 28 Mar 1996 20:00:37 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 79
Message-ID: <4jer55$cdb@park.uvsc.edu>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <31531077.2BB2656B@ids2.idsonline.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20235 comp.unix.bsd.freebsd.misc:16225
[ ... on extended attributes ... ]
Eric Vought <adfh@ids2.idsonline.com> wrote:
] What happens when one file is manipulated by multiple programs? As each
] program stores its associated data in the EA's, the overhead associated
] with that file gradually increases. What happens when you remove an
] application from the system? Does all of its associated EA data
] disappear, do you have to search the entire disk to find and delete the
] data, or does it just quietly sit and eat up space?
These are implementationally naieve questions.
The answers are:
1) Access overhead for the file itself does not change.
2) Attributes are associated at the FS level with the file
node. When the node is removed, the attributes are
also removed.
] Is there a way to register the EA information in an application
] associated and/or user associated space, such that this info can be
] removed easily with the user or the application and such that the actual
] files do not need to be accessed in order to do so?
Yes. It's called "hanging it off the on disk inode" so that
there is a single multiplex instance record.
In a decent file system, when you free a block, you cause an event
to occur. Accounting facilities track these events.
If I delete a file, the EA facility tracks the event and deletes
the attribute, or if implemented as a monolithic system, "it just
works".
] Additionally, how does one transfer a file and its EA's to another
] system? Do you lose all of the data that was carefully stored there, or
] do you carry all of the data with you, including that which is simply
] not relevant to the other machine (possibly including per-user EA data
] for users which do not exist and per-application data for applications
] which do not exist).
This depends on your archiver. Obviously, if you are going to
a machine of the same type, you will want to transfer everything;
otherwise,you will probably only want to transfer the data portion
of the file.
Dearchiving adata that refers to local resources is an issue of
maintaining referential integrity. For instance, if you have a
user "bob" who has associated his own defaults with the file,
and there is no user bob on the new system, it is the job of the
archiver to ensure consistency with the new system environment
when the file is being restored/dearchived.
] Access lists are something which I very much support. The current UNIX
] setup is not versatile enough for many situations. For most of my uses,
] however, it would be sufficient to allow a "root" owner of a subtree
] (ie: a user which has many of the permissions usually ascribed to root
] (like ability to delete sticky files and ability to chown, and override
] permissions), but only within that directory structure and only within
] the confines of a group. This however, does not require EA's.
The problem with inherited rights is imposition of file system
hierarchy. Since hard links damage the ability to determine
inheritance, this means a fundamental change in the mechanism
used to implement hard links. This is actually an easy design
change, assuming variable granularity of the system block store
and a divorce of the in core inode from the in core directory
reference so that open file instances refer to link locations
rather than to the file instance data.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.