>> I wish the BSD people would see how important they are, but then, I
>> feel sorry for the VFS they have to deal with...
>>
>> uriel

really? i'd supposed the bsd vfs was better designed. isn't it? (i hadn't really looked at it
for a years, so that wasn't rhetorical, i was really asking a question.)
the linux one has lots of things in quite the wrong place
because ... all decent files are on proper storage somewhere or they are damned!

On Nov 13, 2007 4:02 PM, Charles Forsyth wrote:
> >> I wish the BSD people would see how important they are, but then, I
> >> feel sorry for the VFS they have to deal with...
> >>
> >> uriel
>
> really? i'd supposed the bsd vfs was better designed. isn't it? (i hadn't really looked at it
> for a years, so that wasn't rhetorical, i was really asking a question.)
> the linux one has lots of things in quite the wrong place
> because ... all decent files are on proper storage somewhere or they are damned!
>

since I'm writing o9fs for OpenBSD I've been dealing with it's VFS for
the last months... the little I've read of linux VFS makes me thing
BSD ones are easy stuff to deal with.

iru

On Nov 13, 2007 10:02 AM, Charles Forsyth wrote:
> >> I wish the BSD people would see how important they are, but then, I
> >> feel sorry for the VFS they have to deal with...
> >>
> >> uriel
>
> really? i'd supposed the bsd vfs was better designed. isn't it? (i hadn't really looked at it
> for a years, so that wasn't rhetorical, i was really asking a question.)
> the linux one has lots of things in quite the wrong place
> because ... all decent files are on proper storage somewhere or they are damned!
>
>

I was of the impression the Linux VFS layer was set up to work well with NFS.

I've no idea how the BSD VFS is these days. Mac OS X had stackable
filesystems for a while, then Apple discouraged that practice
(presumably due to overheads of doing so... so goodbye original
implementation of unionfs).

DragonflyBSD was going to have a VFS based on a message passing system
of sorts... but not 9p :-). That would make things like FUSE pretty
easy I'd think, or 9p for that matter.

FreeBSD may still allow stackable filesystems, but it's hard to tell
where they are because all the cool kids work on linux.

Dave

> DragonflyBSD was going to have a VFS based on a message passing system
> of sorts... but not 9p :-). That would make things like FUSE pretty
> easy I'd think, or 9p for that matter.
>

Not sure where they are yet but here's their idea:

http://www.dragonflybsd.org/docs/goals.shtml#vfsmodel

> Dave
>

On Nov 13, 2007 8:04 PM, David Leimbach wrote:
> I was of the impression the Linux VFS layer was set up to work well with NFS.
>
> I've no idea how the BSD VFS is these days. Mac OS X had stackable
> filesystems for a while, then Apple discouraged that practice
> (presumably due to overheads of doing so... so goodbye original
> implementation of unionfs).
>
OpenBSD has dropped stackable filesystems long ago. The original BSD
unionfs implementation was a nightmare. I started writing a trivial
just for the sake of learning.

> DragonflyBSD was going to have a VFS based on a message passing system
> of sorts... but not 9p :-). That would make things like FUSE pretty
> easy I'd think, or 9p for that matter.
>

I haven't touched the VFS itself, but with o9fs (9P filesystem for
OpenBSD) one should be allow ed to write userland file servers (that's
one of my personal goals).


iru

On Nov 14, 2007 1:19 AM, Iruata Souza wrote:
> I haven't touched the VFS itself, but with o9fs (9P filesystem for
> OpenBSD) one should be allow ed to write userland file servers (that's
> one of my personal goals).

OpenBSD already has filesystems in userland. Look for mount_xfs
(nothing to do with the SGI/linux thing). It is used by their afs client
implementation.

On 11/14/07, R <0xef967c36@gmail.com> wrote:
> OpenBSD already has filesystems in userland. Look for mount_xfs
> (nothing to do with the SGI/linux thing). It is used by their afs client
> implementation.
>

if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
filesystem. if you take a look at /sys/xfs you'll see what have to be
done in the kernel.
o9fs is the only thing residing in the kernel in my case. the userland
filesystem/fileserver could be written entirely in userland with
lib9pclient or libixp.

iru

On Nov 14, 2007 1:44 PM, Iruata Souza wrote:
> On 11/14/07, R <0xef967c36@gmail.com> wrote:
> > OpenBSD already has filesystems in userland. Look for mount_xfs
> > (nothing to do with the SGI/linux thing). It is used by their afs client
> > implementation.
> >
>
> if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
> filesystem. if you take a look at /sys/xfs you'll see what have to be
> done in the kernel.

No, you're wrong !

You can write a new filesystem as a userland daemon - and have
it communicate with the kernel via a /dev/xfs* device.
There's no need for extra code in the kernel.

In fact, that's exactly how afsd (the Andrew Filesystem client, part
of the standard distribution) is working.

This has become off-topic here, I excuse myself to other people
not interested in OpenBSD details, etc ;-)

* R <0xef967c36@gmail.com> [071114 13:19]:
> On Nov 14, 2007 1:44 PM, Iruata Souza wrote:
> > On 11/14/07, R <0xef967c36@gmail.com> wrote:
> > > OpenBSD already has filesystems in userland. Look for mount_xfs
> > > (nothing to do with the SGI/linux thing). It is used by their afs client
> > > implementation.
> > >
> >
> > if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
> > filesystem. if you take a look at /sys/xfs you'll see what have to be
> > done in the kernel.
>
> No, you're wrong !
>
> You can write a new filesystem as a userland daemon - and have
> it communicate with the kernel via a /dev/xfs* device.
> There's no need for extra code in the kernel.
>
> In fact, that's exactly how afsd (the Andrew Filesystem client, part
> of the standard distribution) is working.

You are both right. The AFS daemon runs in userspace. There has to be
a kernel interface to get it into the systems namespace facility
(here it is called VFS). For AFS this interface is very application specific
(/dev/xfs) but Iru's approach would allow to write drivers in userspace and
communicate with the kernel through an application independent interface.

This is what 9p is all about...

--
You may use my gpg key for replies:
pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (OpenBSD)

iD8DBQFHOuyrXYob3Uf3l4gRAtJcAJ0aVPAex2DSrEBdzj3Ci2 HyWJO5nACgoQ1y
+wCflzz72aWv8Wlt8vTrDiQ=
=uQWY
-----END PGP SIGNATURE-----

On Nov 14, 2007 2:40 PM, Christian Kellermann
wrote:
> You are both right. The AFS daemon runs in userspace. There has to be
> a kernel interface to get it into the systems namespace facility
> (here it is called VFS). For AFS this interface is very application specific
> (/dev/xfs) but Iru's approach would allow to write drivers in userspace and

It's a generic interface, not application specific and not tied to AFS
peculiarities.
Think FUSE, only with using character devices instead of unix sockets
to communicate with the userland.

> communicate with the kernel through an application independent interface.
>
> This is what 9p is all about...

* R <0xef967c36@gmail.com> [071114 14:04]:
> Think FUSE, only with using character devices instead of unix sockets
> to communicate with the userland.

indeed. My apologies.
--
You may use my gpg key for replies:
pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (OpenBSD)

iD8DBQFHOvMxXYob3Uf3l4gRAuA6AJ0YBu3KUnwDMILtG+AsrQ yATsIufQCcDQv/
psb2kDj9hc2/f+KfFMjLOp4=
=bSLk
-----END PGP SIGNATURE-----