Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re <lucio.dere@gmail.com>]

On 9/2/18, Brian L. Stuart <blstuart@bellsouth.net> wrote:
> On Sat, 9/1/18, Lucio De Re <lucio.dere@gmail.com> wrote:
>> [ ...  ]
>> My hope is to provide a central file server that fulfills reliable
>> file services to both Plan 9 and Linux as seamlessly as possible. I am
>
> I'm not going to make any guarantees about the reliability,
> but I do have a file system running on Plan 9, that natively
> provides NFS service as well as 9P.

That's definitely a good start.

> I also run it with a
> snapshot device under it and get the type of history we
> expect in a Plan 9 world.  To make the *nix side happy,
> it does support symbolic links.  (Reading a symlink in Plan 9
> just results in the path name string that the link points to.)

Does stat report anything fancy in the case of symbolic links? That
may be all that's needed to handle special applications that are
willing and able... But I will take more than a peek, find there the
answers I seek.

> And to make things really fun, it also serves AOE.
>
I wish...

> I've been running it now on my home system for several
> years.  I honestly don't use the NFS capability all that often,
> but I did test it a fair amount back at Coraid.  Recently, I
> added a little feature to the snapshot device to allow me
> to easily migrate to a larger disk.  As a matter of fact, I read
> your e-mail in acme on a 9vx which was taking its root from
> this file system.

But 9vx (which I nearly worship, but have been reluctant to get
attached to since I've been running 64-bit Linux) uses 9P, so that is
purely of anecdotal interest - I love anecdotes, myself. It's been a
long time, long enough for me to forget whether 9vx will execute Go
binaries or not - now, that's embarrassing!

>
> I'm sure there are plenty of nits that people could pick with
> it and the details of its design, but it was an interesting
> approach to experiment with and it's been serving me
> well for about 4 or 5 years.  The file system itself runs in
> user space on vanilla Plan 9, and the snapshot device
> can be added to the kernel very easily.
>
What nits would you pick, though, being the best qualified to do that?
I have a feeling for your abilities, this may be something 9fans (the
people, not the list) may be able to add much value to, if given some
direction, even I may be able to chip in.

> Although there is a version of both the snapshot device
> and the file system on contrib, if anyone's interested, I
> can get you the most recent code to play with.
>
Not Venti? I like Venti even more than I like 9vx, although
nit-picking there would yield a rich crop :-).

tl;dr: Please upload you efforts to github (or...) unless you have
extreme reasons not to. I'd love to be part of a Plan 9 revival and we
do have a presence on github, let's exploit the time github has got
left.

(GIT is the main reason for my begging here: I "pull" the latest Go to
my workstation, then "archive" to Plan 9 (fossil). But fossil is slow,
too slow to compete even with cross-compiling to plan9_386. Part of
the problem is needing to flush the "archive" target in case bits have
been removed and "export" does not delete them on the target - that
works well, though, with fresh releases, like go1.11, of late. To be
honest, I have the slack to use Plan 9 on a low-powered
server/workstation combination and even cross-produce Linux-64
executables for production; but building the Go distribution isn't
really worth the trouble - I make a special effort to do that, not
often enough.)

Lucio.

PS: I prefer not to be controversial, but Plan 9 needs a bit of
religious fervour to keep it alive: if I need to start a fire under
anyone's buttocks to help along, trust me, I'll do it. :-)