Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.cis.okstate.edu!news.ksu.ksu.edu!lazrus.cca.rockwell.com!newssvr.cacd.rockwell.com!newsrelay.iastate.edu!vixen.cso.uiuc.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: 16 Mar 1996 20:33:42 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 46
Message-ID: <4if8j6$4kh@park.uvsc.edu>
References: <4gejrb$ogj@floyd.sw.oz.au> <4gilab$97u@park.uvsc.edu> <4giqu8$aqk@park.uvsc.edu> <4gira2$a9d@park.uvsc.edu> <hpa.31321eee.I.use.Linux@freya.yggdrasil.com> <4h7t5i$qoh@park.uvsc.edu> <DnoqB4.2sy@pe1chl.ampr.org> <glDH59i00YUvFFjspX@andrew.cmu. <4hptj4$cf4@cville-srv.wam.umd.edu> <4i1t4s$muj@shelby.visix.com> <31462C1C.686CE00F@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19538 comp.unix.bsd.freebsd.misc:15583
Adam Megacz <kalessin@netcom.com> wrote:
] Steve Kiernan wrote:
]
] > Well, you could do what OS/2 does for EAs on a FAT system. It creates a file
] > which has the EAs for each file in the directory, since FAT can't handle the
] > EAs in the file list.
]
] Problems with this:
] 1) It's slow
Because multiple files must be accessed to get one combined
metadata object. This is actually why I included "variable
granularity block store" as one of my feature items for an
"Ideal filesystem".
] 2) If a non-EA supporting kernel accesses the fs, you screw
] up the EA's *big time* (i.e., DOS and OS/2)
This is the "hosted FS" problem. It's ecause all consumers of
the FS don't use the same API to access the FS. UMSDOS has the
same problem. This is why you don't want to do FS hosting except
in private regions which you guarantee, by virtue of their
privacy, only small probability of a user coming in on the hosting
FS and causing problems.
The hosted FS problem is worse on UNIX, where both types of users
can act simultaneously. At least with DOS, the DOS users aren't
going o access the FS using the underlying mechanisms while the
UNIX is up. This is the "host synchronization in a hosted FS"
problem. You'll see it in loopback mounts, NFS, or other areas
where the host FS and the hosted FS API's are exposed simultaneously
(this is why it is a bad thing for Samba to export NFS mounted
FS's).
] 3) It creates major disk fragmentation.
This is a strawman. Whether it creates fragmentation is a
function of the hosting FS. For DOS, it creates fragmentation;
for a modern FS, that really isn't a problem.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.