>> i meant to imply that under the same set of operations and uses (ie,
>> creating, moving and deleting a few files or something like that), the
>> two would be virtually indistinguishable.
>
>Ffs in, lfs maybe, ext2fs out ... perhaps you're trying to say, "Has been
>proven to fully support traditional Unix filesystem semantics, by having
>been an integrated part of BSD Un*x for some years"?

how's this then: if changes are made to ext2fs (or ntfs, or any of the
"non-native" fs types), we (netbsd, that is) will have to play catch
up.  but if changes are made to ffs or lfs, that's changes that we (by
definition) already have, so there's no catch up period.

or do you think the ext2fs people will adopt features that we might
add to out ext2fs code (for example)?

>I must admit that when I wrote out that hierarchy I was subconsciously
>dividing the traditional-ufs-semantics non-volatile filesystems into "BSD"
>and "non-BSD" categories in my head...LFS got lumped in with "BSD" because
>it came from Berkeley (um, and because I'm working on it, so I *want* it
>to be "native" :^)

of course.  :)

>But I'll have to agree with Chris that from an engineering perspective
>there does not seem to be much point in dividing the disk filesystems into
>us/them categories....

yes, true.  it just feels...funny.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."