Re: pkgsrc patches

[Greg Troxel]

Greg Troxel <g...@ir.bbn.com> writes:

On 20011-03-11, I sent a patch to adapt coda to modern NetBSD. On
6.9.5, this patch is still in pkgsrc. Is there some problem with
applying it? (The patch file has a new name, but it's the same bits.)

(Also, is there anybody here?)

$NetBSD: patch-coda-src_venus_worker.cc,v 1.1 2015/01/27 15:21:52 hauke Exp $

Added experimental code to support mounting on NetBSD >= 4.99.24. The
magic value of 256 is taken from coda_vfsops in coda_vfsops.c.

gcc 4.7 on SunOS insists on de-'const'ifying venusRoot.

--- coda-src/venus/worker.cc.orig 2008-10-06 16:52:22.000000000 +0000
+++ coda-src/venus/worker.cc
@@ -403,11 +403,19 @@ void VFSMount()
error = nmount(md, 6, 0);
}
#endif
-
+
+#if defined(__NetBSD__) && __NetBSD_Version__ >= 499002400 /* 4.99.24 */
+ if (error < 0)
+ error = mount("coda", venusRoot, 0, (void *)kernDevice, 256);
+ if (error < 0)
+ error = mount("cfs", venusRoot, 0, (void *)kernDevice, 256);
+#else
if (error < 0)
error = mount("coda", venusRoot, 0, kernDevice);
if (error < 0)
error = mount("cfs", venusRoot, 0, kernDevice);
+#endif
+
#if defined(__FreeBSD__) && !defined(__FreeBSD_version)
#define MOUNT_CFS 19
if (error < 0)
@@ -492,7 +500,8 @@ child_done:
mnttab = fopen(MNTTAB, "a+");
if (mnttab != NULL) {
mt.mnt_special = "CODA";
- mt.mnt_mountp = venusRoot;
+ /* XXX */
+ mt.mnt_mountp = (char *)venusRoot;
mt.mnt_fstype = "CODA";
mt.mnt_mntopts = "rw";
mt.mnt_time = tm;

[Jan Harkes]

On Tue, Jan 27, 2015 at 02:39:32PM -0500, Greg Troxel wrote:
>
> Greg Troxel <g...@ir.bbn.com> writes:
>
> On 20011-03-11, I sent a patch to adapt coda to modern NetBSD. On
> 6.9.5, this patch is still in pkgsrc. Is there some problem with
> applying it? (The patch file has a new name, but it's the same bits.)
>
> (Also, is there anybody here?)

Yes someone is here.

Haven't checked yet if the patch is applied to CVS, but I have a couple
of emails with Coda related patches that were sent to codalist and me
privately tagged to be applied.

I figured I'd apply them after the CVS -> Git conversion was complete
and then release a new Coda version with the state of things. I've
scripted the whole conversion process with reposurgeon and stopped
trying to 'perfect' the conversion mostly because I seemed to be getting
stuck on reposurgeon related bugs.

The only remaining step is to validate that the source of the released
versions of Coda actually match the tagged commits. I tried to automate
the check, but due to subtle differences because of CVS/RCS tag
expansions and such it looks like it might have to be done manually by
unpacking a released tar and then diffing against a checked out release
and reading the diffs to see if any of the differences are significant.

> +#if defined(__NetBSD__) && __NetBSD_Version__ >= 499002400 /* 4.99.24 */
> + if (error < 0)
> + error = mount("coda", venusRoot, 0, (void *)kernDevice, 256);
> + if (error < 0)
> + error = mount("cfs", venusRoot, 0, (void *)kernDevice, 256);
> +#else

I don't like the inline #ifdef style, but I can see that any other
solution would just push the ifdef into a worse place. btw. what does
the 256 stand for? shouldn't it include a header and use the symbolic
name?

Jan

[Greg Troxel]

Jan Harkes <jaha...@cs.cmu.edu> writes:

> Yes someone is here.

Glad to hear it.

> Haven't checked yet if the patch is applied to CVS, but I have a couple
> of emails with Coda related patches that were sent to codalist and me
> privately tagged to be applied.
>
> I figured I'd apply them after the CVS -> Git conversion was complete
> and then release a new Coda version with the state of things. I've
> scripted the whole conversion process with reposurgeon and stopped
> trying to 'perfect' the conversion mostly because I seemed to be getting
> stuck on reposurgeon related bugs.

If that's soon, that's fine. I see getting buffixes applied and patch
release out as more important than converting. I'm all for switching to
git, but it's not coda's biggest problem.

> The only remaining step is to validate that the source of the released
> versions of Coda actually match the tagged commits. I tried to automate
> the check, but due to subtle differences because of CVS/RCS tag
> expansions and such it looks like it might have to be done manually by
> unpacking a released tar and then diffing against a checked out release
> and reading the diffs to see if any of the differences are significant.

It sounds encouraging that this is the level of issue you are down to
(really).

>> +#if defined(__NetBSD__) && __NetBSD_Version__ >= 499002400 /* 4.99.24 */
>> + if (error < 0)
>> + error = mount("coda", venusRoot, 0, (void *)kernDevice, 256);
>> + if (error < 0)
>> + error = mount("cfs", venusRoot, 0, (void *)kernDevice, 256);
>> +#else
>
> I don't like the inline #ifdef style, but I can see that any other
> solution would just push the ifdef into a worse place. btw. what does
> the 256 stand for? shouldn't it include a header and use the symbolic
> name?

A fair comment. Basically, mount's signature is

int
mount(const char *type, const char *dir, int flags, void *data,
size_t data_len);

So it's the size of the kernDevice object. Probably "sizeof(*
kernDevice)" is apppropriate. I can check that soon.

Also, there are solaris patches just arrived in pkgsrc. I am unclear on
whether that means someone has the kernel code working, or if it's just
part of a "make all packages build on $OS" rampage. But they look like
cleanups that ought to be applied anyway. One issue is being careful to
use the stdint types consistently.

With the change to git, will there be a bugtracker? It seems we don't
have one now, or at least I'm unaware.

[Jan Harkes]

On Tue, Jan 27, 2015 at 04:11:38PM -0500, Greg Troxel wrote:
> Jan Harkes <jaha...@cs.cmu.edu> writes:
>
> > Yes someone is here.
>
> Glad to hear it.
>
> > Haven't checked yet if the patch is applied to CVS, but I have a couple
> > of emails with Coda related patches that were sent to codalist and me
> > privately tagged to be applied.
> >
> > I figured I'd apply them after the CVS -> Git conversion was complete
> > and then release a new Coda version with the state of things. I've
> > scripted the whole conversion process with reposurgeon and stopped
> > trying to 'perfect' the conversion mostly because I seemed to be getting
> > stuck on reposurgeon related bugs.
>
> If that's soon, that's fine. I see getting buffixes applied and patch
> release out as more important than converting. I'm all for switching to
> git, but it's not coda's biggest problem.

All my scripts that I used to use to build, test, tag, package and sign
new releases have broken over time so actually making a new release will
take some time on my end to dig up on which USB drive I have my signing
keys and such. So I figured instead of fixing the release scripts for
CVS, finishing Git conversion and then rewriting the release scripts for
Git I could just do the fix once and be done. But the conversion is
taking pretty long partly because 'it aint the biggest problem'.

> With the change to git, will there be a bugtracker? It seems we don't
> have one now, or at least I'm unaware.

Yes, our group has public and private Github repositories under
https://github.com/cmusatyalab/ and the converted Coda source repo
would be published there too.

Jan

[Hauke Fath]

On Tue, 27 Jan 2015 16:11:38 -0500, Greg Troxel wrote:
> Also, there are solaris patches just arrived in pkgsrc. I am unclear on
> whether that means someone has the kernel code working,

No, unfortunately not...

> or if it's just
> part of a "make all packages build on $OS" rampage.

Not that, either.

I am looking at how my group could use Coda to be less dependent on a
working network. Since the fileserver runs OI, I made Coda build there,
and only after the commit I realised there was an important bit missing
(<http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest
news I could find).

> But they look like cleanups that ought to be applied anyway.

Yes, it was mostly #including headers that are not implicitely included
on Solaris OSes (Open Indiana here), and the odd compiler issue.

Cheerio,
hauke

--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-3281

[Greg Troxel]

Hauke Fath <h...@spg.tu-darmstadt.de> writes:

> On Tue, 27 Jan 2015 16:11:38 -0500, Greg Troxel wrote:
>> Also, there are solaris patches just arrived in pkgsrc. I am unclear on
>> whether that means someone has the kernel code working,
>

> I am looking at how my group could use Coda to be less dependent on a
> working network. Since the fileserver runs OI, I made Coda build there,
> and only after the commit I realised there was an important bit missing
> (<http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest
> news I could find).

To really be able to use coda, it has to be both reliable and portable.
Right now both are issues.

For portability, the problem is that it only runs on NetBSD and Linux,
as far as I know.

For reliability, it mostly works, but it's too easy to get venus hung
up. On upgrading from NetBSD 5 to 6, I found two bugs. One was a
regression in mmap/munmap of coda files in the kernel interface due to
some new assert. I worked around that by disabling mmap. The other is
that removing a directory leads to venus spinning, and I haven't
investigated.

I can see two ways forward:

Make a FUSE interface for venus, so that it will run just about
everywhere.*

Create a new (FUSE-based) filesystem that is much like the current
system, but can do write-disconnected caching based on some other
filesystem that doesn't handle disconnects (sshfs, gluster). Ideally
it would work with stored metadata that can mostly function even if
other users don't do this. And maybe work extra well if all users do
use it. This is sort of like unison.

For your use case, I think you should probably add FUSE to venus. This
is probably not exceedingly hard, and I suspect it is easier than
writing a kernel module.

People will probably say that this will cause performance problems; the
current kernel module forwards file operations in-kernel to the
container file, so read/write are at native speed. That was probably
very important back in 1997, and there was no FUSE then. But now,
gluster via FUSE achieves near Gigabit speeds on NetBSD. And, I
personally would far rather have filesystem that works on all the
computers I want to use than to have it be fast on a few and totally
nonfunctional on the rest. But, if venus has the current kernel
interface and FUSE, those who want performance can use the present
interface, or implement it on more systems.

* I have no idea what that means for Windows. But Windows is outside my
definition of "just about everywhere"...

[Phil Nelson]

On Wednesday 28 January 2015 08:48:37 Greg Troxel wrote:
> For portability, the problem is that it only runs on NetBSD and Linux,
> as far as I know.

That is most likely true at the current time, but there is code that
exits that, with a little work, could get Coda running on Windows
again. Also, I seem to remember that there was a 32-bit version
of a kernel module for Solaris. I was looking for a copy of the
sources, but I haven't worked with them for quite a while. I'm
sure Jan could look for them. I don't know if it would be easier
to write a FUSE driver or to get the Solaris kernel module updated.
Using FUSE is possibly the better long term solution.

--Phil

--
Phil Nelson, http://pcnelson.net

[u-t...@aetey.se]

On Wed, Jan 28, 2015 at 11:48:37AM -0500, Greg Troxel wrote:
> > <http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest
> > news
>

> To really be able to use coda, it has to be both reliable and portable.
> Right now both are issues.
>

> For portability, the problem is that it only runs on NetBSD and Linux,
> as far as I know.

Sadly, this is correct, several platforms has lost the support with time.
The main reason seems to be that even the relatively simple Coda kernel part
is not "simple enough" to be correctly ported between OS versions
without a Coda-specific knowledge which developers generally lack.

Coda is still inside the moment 22 (too few users because of limited
development, too little development due to lack of competence, too little
people with competence because of too few users). Still it is alive and
performing reasonably - with no comparable replacement so we who depend
on it are kind of forced to keep it alive! :)

I wish we would do more than just "keep it alive".

> For reliability, it mostly works, but it's too easy to get venus hung
> up. On upgrading from NetBSD 5 to 6, I found two bugs. One was a
> regression in mmap/munmap of coda files in the kernel interface due to
> some new assert. I worked around that by disabling mmap. The other is
> that removing a directory leads to venus spinning, and I haven't
> investigated.

Hope you find some more time to work on this. It would be just too bad
not having Coda on NetBSD.

> I can see two ways forward:
>
> Make a FUSE interface for venus, so that it will run just about
> everywhere.*

Concerning "about everywhere" - I am unsure whether FUSE is portable to
the necessary degree, i.e. provides the necessary facilities "everywhere"
- Coda is a quite non-traditional file system while I _guess_ that FUSE
is implemented in different kernels in the first hand with the most
common file system abstraction in mind.

> Create a new (FUSE-based) filesystem that is much like the current
> system, but can do write-disconnected caching based on some other
> filesystem that doesn't handle disconnects (sshfs, gluster). Ideally
> it would work with stored metadata that can mostly function even if
> other users don't do this. And maybe work extra well if all users do
> use it. This is sort of like unison.

I do not wish to sound negative but feel some doubts nevertheless.

Would it really be easier to implement the Coda security and consistenly
model (in presence of disconnections) over a different file-system-like
storage, compared to talking to Coda-specific servers like we do now?

> For your use case, I think you should probably add FUSE to venus. This
> is probably not exceedingly hard, and I suspect it is easier than
> writing a kernel module.

If done in a portable (not Solaris-specific) fashion a FUSE-Coda-client
would be certainly an extremely welcome contribution for other platforms
too. Otherwise, with Solaris kernel knowledge, a kernel module can
be easier.

> I personally would far rather have filesystem that works on all the
> computers I want to use than to have it be fast on a few and totally
> nonfunctional on the rest. But, if venus has the current kernel
> interface and FUSE, those who want performance can use the present
> interface, or implement it on more systems.

I would be happy to trade some performance against universality and
lower maintenance costs. I would happily trade even much more for a
fully user-space implementation, which is possible without FUSE and thus
without the superuser privileges.

The main problem is that we who need the functionality have no redundant
resources to do the development. In other words, the benefits of Coda
do not bring in enough money to make the development of Coda sustainable.

Research drove the development for quite a while (thanks Satya!) but it
had different goals than to build a "production system". For the latter
nobody has invested the necessary amount. I have not any good answer to
how to solve this. A technical/conceptual superiority does not necessarily
imply adoption in a profit-driven infrastructure (because of the conflict
between the short-term survival and long term benefits).

> * I have no idea what that means for Windows. But Windows is outside my
> definition of "just about everywhere"...

Hardly a regression anyway - the last version of Windows (XP) which had
Coda is no longer with us. On the other side a Coda to Samba gateway on
Linux is "relatively trivial" :)

Rune