0.6.9

[sgheeren]

Peeps

I have been busy.

I wanted to give proper thought to some of the issues (like #47). After spending some time I have come up with

(a) a much needed cleanup of some of the threading/shutdown logic in the zfs-fuse daemon (see issue47 branch on sehe.nl [1]
(b) a workaround adapted from Emmanuels fff6bda224d (adding sleeps)

I intend to release the current state of the testing branch tomorrow as 0.6.9. [3]
I think (a) will facilitate some other simplifications down the road, perhaps leading to elimination of these timing-related issues if at all possible. I have also found some good inroads into (perhaps) making ctldir (.zfs) work with zfs-fuse [2]. I sometimes get the feeling I might be starting to 'get' this beast :)


Cheers,
Seth


[1] http://zfs-fuse.sehe.nl/?p=zfs-fuse;a=shortlog;h=refs/heads/issue47
[2] without resorting to using 'zfs clone' from userspace, because it simply doesn't scale well and has sideeffects not seen on Solaris
[3] That will be around 21:00 CET

[sgheeren]

Hello gents

I'm still kind of busy, so dropping a small note here:

http://zfs-fuse.net/releases/0.6.9

Thanks for all the  energy you all put into testing this baby out. I'm positive that we have a solid release here.
Also, we have quite upped the pace of development by getting much more active bug-reporting spirit going.

Now, if someone feels like writing a little piece of text for the zfs-fuse homepage? I can publish it if anyone wants to contribute but isn't a website admin just yet.

Seth

[3] That will be around 21:00 CET --
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

[Vincent Cojot]

Juste a quick note, trying to build on RHEL5.5 gives:

se/ptrace.c
gcc -o zfs-fuse/util.o -c -pipe -Wall -std=c99 -Wno-switch -Wno-unused -Wno-missing-braces -Wno-parentheses -Wno-uninitialized -fno-strict-aliasing -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DTEXT_DOMAIN=\"zfs-fuse\" -s -O2 -DNDEBUG -D_KERNEL -DLINUX_AIO -Ilib/libavl/include -Ilib/libnvpair/include -Ilib/libumem/include -Ilib/libzfscommon/include -Ilib/libsolkerncompat/include zfs-fuse/util.c
zfs-fuse/util.c: In function 'zfsfuse_do_locking':
zfs-fuse/util.c:99: error: 'O_CLOEXEC' undeclared (first use in this function)
zfs-fuse/util.c:99: error: (Each undeclared identifier is reported only once
zfs-fuse/util.c:99: error: for each function it appears in.)

0.6.9_beta3 and previous rpmbuilt fine before...

Vincent

[Vincent Cojot]

Also, looks like we need to be careful here because O_ATOMICLOOKUP in
RHEL4 and RHEL5 kernels uses the same flag number that O_CLOEXEC flag
in latest mainstream kernels

(see https://bugzilla.redhat.com/show_bug.cgi?id=313681)

[Vincent Cojot]

I got around that issue with the following patch:

*** zfs-fuse-0.6.9/src/zfs-fuse/util.c.orig Fri Jun 4 10:30:54 2010
--- zfs-fuse-0.6.9/src/zfs-fuse/util.c Fri Jun 4 10:29:34 2010
***************
*** 96,102 ****
--- 96,106 ----
* first byte; the file /must/ already exist. Only in this way can we
* prevent races with locking before or after the daemonization
*/
+ #ifdef O_CLOEXEC
lock_fd = open(LOCKFILE, O_WRONLY|O_CLOEXEC);
+ #else
+ lock_fd = open(LOCKFILE, O_WRONLY);
+ #endif
if(lock_fd == -1)
return -1;

Would that be acceptable?
Looking more closely at the issue, O_ATOMICLOOKUP vs O_CLOEXEC is
only an issue on early RHEL5.x released (it was fixed after 5.2, I
think).
My 2c,
Vincent

[Emmanuel Anne]

I didn't even merge this patch yet (the one with O_CLOEXEC).
It doesn't really look like a patch for a final beta just before a release, but anyway...

2010/6/4 Vincent Cojot <vin...@cojot.name>

--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[Vincent Cojot]

Hi Emmanuel,

BYW, thanks guys for the hard work. It's great to have ZFS under Linux.
I ran into the O_CLOEXEC issue when I downloaded
http://zfs-fuse.net/releases/0.6.9/source-tarball.
So I don't know where it wasn't merged because I got it from the
tarball release. :) I have no idea if my fix is correct but zfs
0.6.9+patch appears to compile and work properly under RHEL5.5/x86_64
so far.
Best regards,

Vincent

[Emmanuel Anne]

Yeah well it's probably correct since we didn't use this flag before. Wait for the comments of Seth about this, it's his work there.

2010/6/4 Vincent Cojot <vin...@cojot.name>

--

To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

[devsk]

The release needs to be highlighted in popular websites...

This is major update to a project which many think is dead!

-devsk

On Jun 4, 11:18 am, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Yeah well it's probably correct since we didn't use this flag before. Wait
> for the comments of Seth about this, it's his work there.
>

> 2010/6/4 Vincent Cojot <vinc...@cojot.name>

>
>
>
> > Hi Emmanuel,
>
> > BYW, thanks guys for the hard work. It's great to have ZFS under Linux.
> > I ran into the O_CLOEXEC issue when I downloaded
> >http://zfs-fuse.net/releases/0.6.9/source-tarball.
> > So I don't know where it wasn't merged because I got it from the
> > tarball release. :) I have no idea if my fix is correct but zfs
> > 0.6.9+patch appears to compile and work properly under RHEL5.5/x86_64
> > so far.
> > Best regards,
>
> > Vincent
>

> > On Fri, Jun 4, 2010 at 6:42 PM, Emmanuel Anne <emmanuel.a...@gmail.com>

> > wrote:
> > > I didn't even merge this patch yet (the one with O_CLOEXEC).
> > > It doesn't really look like a patch for a final beta just before a
> > release,
> > > but anyway...
>
> > --
> > To post to this group, send email to zfs-...@googlegroups.com

> > To visit our Web site, click onhttp://zfs-fuse.net/

[sgheeren]

Bug filed. Resolution on testing branch

[sgheeren]

Yes that looks acceptable. However, on re-reading the man page I found
that the use of O_CLOEXEC was misguided in this particular case. I opted
to remove it (see testing branch and issue #53)

[sgheeren]

On 06/04/2010 06:42 PM, Emmanuel Anne wrote:
> I didn't even merge this patch yet (the one with O_CLOEXEC).
> It doesn't really look like a patch for a final beta just before a release,
> but anyway...
>

Well... Pardon me? The beta is there for a reason (testing).

I _have_ tried to run a 'tight' ship[0]. There are many things I have
chosen not to merge into testing.

We have been addressing just the issues mentioned on the list[1] during
the period of planning for 0.6.9

I personally think it is a good idea to fix it when it's found.
I do hope you are not confusing stabilizing changes with wild
experimentation :) I did stabilize some of your own 'wilder' (indulge
me...) changes as well. Still I'm thanking you for coming up with the
changes in the first place because - well, we all love to send|recv, for
example!

Cheers

[0] See e.g.
http://groups.google.com/group/zfs-fuse/msg/e53412ae15df1b99. The patch
for initialization order has only been pushed to testing _AFTER_ the fix
for lockfile behaviour was made and tested... Still the CLOEXEC is a
glitch, sorry
[1] except for a spurious old patch that I had lying around (dae0b2f8)
[2] Also, 6 commits before the last beta, which dates a full week back
is not what I call 'just before a release'

[sgheeren]

On 06/04/2010 07:46 PM, Vincent Cojot wrote:
> I have no idea if my fix is correct but zfs
>

Why not? http://zfs-fuse.net/issues/53