Creating a symlink makes zfs-fuse disable xattr support
86 views
Skip to first unread message
Hannes Landeholm
Aug 18, 2011, 12:19:09 PM8/18/11
to zfs-fuse
Hello,
I've just installed zfs-fuse_0.7.0 on my clean ubuntu natty box. I
installed zfs using "dpkg -i zfs-fuse_0.7.0-1_amd64.deb"
I'm having crazy troubles getting xattr to work though (I need xattr
support).
So I first tried to uncomment the row:
# enable-xattr
in /etc/zfs/zfsrc - however zfs-fuse refused to give me a warning when
starting. Interestingly enough it recognizes "enable-xattr" but
refuses to actually enable xattr when starting. I had to change the
line to "x" which is the shorthand for enable-xattr. This made zfs-
fuse give me the warning:
/sbin/zfs-fuse: Warning: enabling xattr support should only be done
when really required; performance will be affected
..which indicated that it worked. Now I proceeded to create a raid0
pool of two disk partitions. I checked that xattr worked and it did.
But suddenly when using the mounted volume xattr where suddenly
disabled. I found after lots of troubleshooting that creating a
symlink anywhere with any name actually made zfs-fuse disable xattr
support for some reason. You can see this strange behavior in this
link:
http://pastebin.com/EkqmZ1np
What's going on?
I've just installed zfs-fuse_0.7.0 on my clean ubuntu natty box. I
installed zfs using "dpkg -i zfs-fuse_0.7.0-1_amd64.deb"
I'm having crazy troubles getting xattr to work though (I need xattr
support).
So I first tried to uncomment the row:
# enable-xattr
in /etc/zfs/zfsrc - however zfs-fuse refused to give me a warning when
starting. Interestingly enough it recognizes "enable-xattr" but
refuses to actually enable xattr when starting. I had to change the
line to "x" which is the shorthand for enable-xattr. This made zfs-
fuse give me the warning:
/sbin/zfs-fuse: Warning: enabling xattr support should only be done
when really required; performance will be affected
..which indicated that it worked. Now I proceeded to create a raid0
pool of two disk partitions. I checked that xattr worked and it did.
But suddenly when using the mounted volume xattr where suddenly
disabled. I found after lots of troubleshooting that creating a
symlink anywhere with any name actually made zfs-fuse disable xattr
support for some reason. You can see this strange behavior in this
link:
http://pastebin.com/EkqmZ1np
What's going on?
sgheeren
Aug 18, 2011, 3:10:49 PM8/18/11
to zfs-...@googlegroups.com
I have a hunch where to look. Brb
Emmanuel Anne
Aug 18, 2011, 3:40:49 PM8/18/11
to zfs-...@googlegroups.com
Errr, well I use all the time (well not all the time, but everytime I need to use xattrs) the long option in zfsrc (enable-xattr) and never had any problem with it.
And I just used it now, and it enabled the xattrs correctly.
But now the problem is that indeed xattrs can't work with the latest version, I hadn't noticed that the interface for xattrs has completely changed with zpool version 24 (system attributes), the symlink problem is probably just a coincidence.
You can test with something like
setfattr -n thing -v dummy file
getfattr -d -m - file
-> Not supported operation.
Actually you should avoid to use xattrs completely for now because the lookup is not done correctly. The fix should not be hard to do though, it's just that this thing was not noticed. So thanks for noticing !
--
my zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
And I just used it now, and it enabled the xattrs correctly.
But now the problem is that indeed xattrs can't work with the latest version, I hadn't noticed that the interface for xattrs has completely changed with zpool version 24 (system attributes), the symlink problem is probably just a coincidence.
You can test with something like
setfattr -n thing -v dummy file
getfattr -d -m - file
-> Not supported operation.
Actually you should avoid to use xattrs completely for now because the lookup is not done correctly. The fix should not be hard to do though, it's just that this thing was not noticed. So thanks for noticing !
2011/8/18 Hannes Landeholm <land...@gmail.com>
--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/
--
my zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
Hannes Landeholm
Aug 18, 2011, 4:24:08 PM8/18/11
to zfs-fuse
Great, so if it's an easy fix, are there any possibility of a quick
patch and a new minor release increment right now then?
~Hannes
On Aug 18, 9:40 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Errr, well I use all the time (well not all the time, but everytime I need
> to use xattrs) the long option in zfsrc (enable-xattr) and never had any
> problem with it.
> And I just used it now, and it enabled the xattrs correctly.
>
> But now the problem is that indeed xattrs can't work with the latest
> version, I hadn't noticed that the interface for xattrs has completely
> changed with zpool version 24 (system attributes), the symlink problem is
> probably just a coincidence.
>
> You can test with something like
> setfattr -n thing -v dummy file
> getfattr -d -m - file
> -> Not supported operation.
>
> Actually you should avoid to use xattrs completely for now because the
> lookup is not done correctly. The fix should not be hard to do though, it's
> just that this thing was not noticed. So thanks for noticing !
>
> 2011/8/18 Hannes Landeholm <landeh...@gmail.com>
> > To visit our Web site, click onhttp://zfs-fuse.net/
patch and a new minor release increment right now then?
~Hannes
On Aug 18, 9:40 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Errr, well I use all the time (well not all the time, but everytime I need
> to use xattrs) the long option in zfsrc (enable-xattr) and never had any
> problem with it.
> And I just used it now, and it enabled the xattrs correctly.
>
> But now the problem is that indeed xattrs can't work with the latest
> version, I hadn't noticed that the interface for xattrs has completely
> changed with zpool version 24 (system attributes), the symlink problem is
> probably just a coincidence.
>
> You can test with something like
> setfattr -n thing -v dummy file
> getfattr -d -m - file
> -> Not supported operation.
>
> Actually you should avoid to use xattrs completely for now because the
> lookup is not done correctly. The fix should not be hard to do though, it's
> just that this thing was not noticed. So thanks for noticing !
>
sgheeren
Aug 18, 2011, 4:40:33 PM8/18/11
to zfs-...@googlegroups.com
On 08/18/2011 09:40 PM, Emmanuel Anne wrote:
Errr, well I use all the time (well not all the time, but everytime I need to use xattrs) the long option in zfsrc (enable-xattr) and never had any problem with it.
And I just used it now, and it enabled the xattrs correctly.
I found out a glitch that exists only in master and main; it is
already fixed in testing and unstable (don't know why).
I've submitted an updated deb source package to the ubuntu build servers; The fixed package should be available in 2-8 hours according to the current build queue:
https://launchpad.net/~bugs-sehe/+archive/zfs-fuse/+builds
I've submitted an updated deb source package to the ubuntu build servers; The fixed package should be available in 2-8 hours according to the current build queue:
https://launchpad.net/~bugs-sehe/+archive/zfs-fuse/+builds
On 08/18/2011 09:40 PM, Emmanuel Anne wrote:
You can test with something like
setfattr -n thing -v dummy file
getfattr -d -m - file
-> Not supported operation.
With me (on maint/testing:)
However, I don't know what you meant by 'the lookup is not done right', Emmanuel?
root@natty:/tmp/tanq# setfattr -n thing -v dummy fileNo problems... Linking files didn't change that. So I think Emmanuel is right that the relation with 'ln' is spurious.
root@natty:/tmp/tanq# getfattr -d -m - file
# file: file
thing="dummy"
However, I don't know what you meant by 'the lookup is not done right', Emmanuel?
Emmanuel Anne
Aug 18, 2011, 5:01:10 PM8/18/11
to zfs-...@googlegroups.com
Ok, it's fixed, I'll commit the fix just after posting this mail.
So the details :
for some reason sun changed the way xattr lookups are done on symlinks, so it's really related to symlinks after all. When you try to do a getxattr on a symlink (or any xattr function anyway), it returns ENOSYS.
Well that's very nice and all, but if you do this to fuse, it will consider that xattrs are not supported on this fs and will never call the function again, returning ENOSYS all the time !
So a quick fix is to return ENOATTR instead of ENOSYS at this place (this is when it tries to lookup the directory containing xattrs).
To reproduce the bug with the not patched version :
setfxattr -n thing -v value file
getfattr -d -m - file
-> works
then ls any symlink on the filesystem,
Then getfattr -d -m - file
-> not supported
So the details :
for some reason sun changed the way xattr lookups are done on symlinks, so it's really related to symlinks after all. When you try to do a getxattr on a symlink (or any xattr function anyway), it returns ENOSYS.
Well that's very nice and all, but if you do this to fuse, it will consider that xattrs are not supported on this fs and will never call the function again, returning ENOSYS all the time !
So a quick fix is to return ENOATTR instead of ENOSYS at this place (this is when it tries to lookup the directory containing xattrs).
To reproduce the bug with the not patched version :
setfxattr -n thing -v value file
getfattr -d -m - file
then ls any symlink on the filesystem,
Then getfattr -d -m - file
-> not supported
2011/8/18 sgheeren <sghe...@hotmail.com>
--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/
Hannes Landeholm
Aug 18, 2011, 5:20:34 PM8/18/11
to zfs-fuse
Umm.. I'm just looking at the source code right now to research why
had to use "x" instead of "enable-xattr".
main.c:158
{ "enable-xattr",
0,
&cf_enable_xattr,
0
},
Shouldn't the last 0 in this struct be a 1? getopt.h tells me this is
the value that is set into the int* specified by the third parameter.
~Hannes
had to use "x" instead of "enable-xattr".
main.c:158
{ "enable-xattr",
0,
&cf_enable_xattr,
0
},
Shouldn't the last 0 in this struct be a 1? getopt.h tells me this is
the value that is set into the int* specified by the third parameter.
~Hannes
Emmanuel Anne
Aug 18, 2011, 5:23:59 PM8/18/11
to zfs-...@googlegroups.com
Yes the last parameter should be 1, everything is fixed now anyway.
2011/8/18 Hannes Landeholm <land...@gmail.com>
--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/
Hannes Landeholm
Aug 18, 2011, 5:55:34 PM8/18/11
to zfs-fuse
By the way, my main problem is really that ZFS does not support xattr
on symlinks at all. This is the related bug for the zfs kernel
project:
https://github.com/zfsonlinux/zfs/issues/272
It's a small issue which makes it incompatible to run a ZFS + gluster
stack. Is it possible to make a workaround for this in zfs-fuse so the
sun code actually stores xattr's for symlinks instead of returning
ENOSYS?
Here is another related link:
http://download.gluster.com/pub/gluster/glusterfs/doc/solaris-related-xattrs.txt
~Hannes
On Aug 18, 11:01 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Ok, it's fixed, I'll commit the fix just after posting this mail.
> So the details :
>
> for some reason sun changed the way xattr lookups are done on symlinks, so
> it's really related to symlinks after all. When you try to do a getxattr on
> a symlink (or any xattr function anyway), it returns ENOSYS.
> Well that's very nice and all, but if you do this to fuse, it will consider
> that xattrs are not supported on this fs and will never call the function
> again, returning ENOSYS all the time !
> So a quick fix is to return ENOATTR instead of ENOSYS at this place (this is
> when it tries to lookup the directory containing xattrs).
>
> To reproduce the bug with the not patched version :
> setfxattr -n thing -v value file
> getfattr -d -m - file
> -> works
> then ls any symlink on the filesystem,
> Then getfattr -d -m - file
> -> not supported
>
> 2011/8/18 sgheeren <sghee...@hotmail.com>
>
>
>
>
>
>
>
>
>
> > **
on symlinks at all. This is the related bug for the zfs kernel
project:
https://github.com/zfsonlinux/zfs/issues/272
It's a small issue which makes it incompatible to run a ZFS + gluster
stack. Is it possible to make a workaround for this in zfs-fuse so the
sun code actually stores xattr's for symlinks instead of returning
ENOSYS?
Here is another related link:
http://download.gluster.com/pub/gluster/glusterfs/doc/solaris-related-xattrs.txt
~Hannes
On Aug 18, 11:01 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Ok, it's fixed, I'll commit the fix just after posting this mail.
> So the details :
>
> for some reason sun changed the way xattr lookups are done on symlinks, so
> it's really related to symlinks after all. When you try to do a getxattr on
> a symlink (or any xattr function anyway), it returns ENOSYS.
> Well that's very nice and all, but if you do this to fuse, it will consider
> that xattrs are not supported on this fs and will never call the function
> again, returning ENOSYS all the time !
> So a quick fix is to return ENOATTR instead of ENOSYS at this place (this is
> when it tries to lookup the directory containing xattrs).
>
> To reproduce the bug with the not patched version :
> setfxattr -n thing -v value file
> getfattr -d -m - file
> -> works
> then ls any symlink on the filesystem,
> Then getfattr -d -m - file
> -> not supported
>
>
>
>
>
>
>
>
>
>
> > **
> > On 08/18/2011 09:40 PM, Emmanuel Anne wrote:
>
> > Errr, well I use all the time (well not all the time, but everytime I need
> > to use xattrs) the long option in zfsrc (enable-xattr) and never had any
> > problem with it.
> > And I just used it now, and it enabled the xattrs correctly.
>
> > I found out a glitch that exists only in master and main; it is already
> > fixed in testing and unstable (don't know why).
>
> > I've submitted an updated deb source package to the ubuntu build servers;
> > The fixed package should be available in 2-8 hours according to the current
> > build queue:
>
> >https://launchpad.net/~bugs-sehe/+archive/zfs-fuse/+builds<https://launchpad.net/%7Ebugs-sehe/+archive/zfs-fuse/+builds>
>
> > Errr, well I use all the time (well not all the time, but everytime I need
> > to use xattrs) the long option in zfsrc (enable-xattr) and never had any
> > problem with it.
> > And I just used it now, and it enabled the xattrs correctly.
>
> > I found out a glitch that exists only in master and main; it is already
> > fixed in testing and unstable (don't know why).
>
> > I've submitted an updated deb source package to the ubuntu build servers;
> > The fixed package should be available in 2-8 hours according to the current
> > build queue:
>
>
> > On 08/18/2011 09:40 PM, Emmanuel Anne wrote:
>
> > You can test with something like
> > setfattr -n thing -v dummy file
> > getfattr -d -m - file
> > -> Not supported operation.
>
> > With me (on maint/testing:)
>
> > root@natty:/tmp/tanq# setfattr -n thing -v dummy file
> > root@natty:/tmp/tanq# getfattr -d -m - file
> > # file: file
> > thing="dummy"
>
> > No problems... Linking files didn't change that. So I think Emmanuel is
> > right that the relation with 'ln' is spurious.
>
> > However, I don't know what you meant by 'the lookup is not done right',
> > Emmanuel?
>
> > --
> > To post to this group, send email to zfs-...@googlegroups.com
> > To visit our Web site, click onhttp://zfs-fuse.net/
> > On 08/18/2011 09:40 PM, Emmanuel Anne wrote:
>
> > You can test with something like
> > setfattr -n thing -v dummy file
> > getfattr -d -m - file
> > -> Not supported operation.
>
> > With me (on maint/testing:)
>
> > root@natty:/tmp/tanq# setfattr -n thing -v dummy file
> > root@natty:/tmp/tanq# getfattr -d -m - file
> > # file: file
> > thing="dummy"
>
> > No problems... Linking files didn't change that. So I think Emmanuel is
> > right that the relation with 'ln' is spurious.
>
> > However, I don't know what you meant by 'the lookup is not done right',
> > Emmanuel?
>
> > --
> > To post to this group, send email to zfs-...@googlegroups.com
Emmanuel Anne
Aug 18, 2011, 5:58:38 PM8/18/11
to zfs-...@googlegroups.com
Yes it's a strange story, it didn't work this way before, I wonder what they did with symlinks. Well I'll need more time to look at that, I'll try to take a look tomorrow...
2011/8/18 Hannes Landeholm <land...@gmail.com>
To visit our Web site, click on http://zfs-fuse.net/
Emmanuel Anne
Aug 18, 2011, 6:25:57 PM8/18/11
to zfs-...@googlegroups.com
Well finally I was not sleepy yet, so I took a look and the problem was VERY easy.
Apparently it's just someone at sun who forgot to transfer the lookup operation to the table of operations for symlinks. This is one of the rare things which is easy to do on the zfs source (like adding new compression methods !).
Anyway xattrs on symlinks work again now, and so I removed my previous patch.
Apparently it's just someone at sun who forgot to transfer the lookup operation to the table of operations for symlinks. This is one of the rare things which is easy to do on the zfs source (like adding new compression methods !).
Anyway xattrs on symlinks work again now, and so I removed my previous patch.
2011/8/18 Emmanuel Anne <emmanu...@gmail.com>
Hannes Landeholm
Aug 18, 2011, 6:34:23 PM8/18/11
to zfs-fuse
That's great!
Does it also works on symlinks in the sense that symlinks have their
own xattrs? (XATTR_NOFOLLOW support)
~Hannes
On Aug 19, 12:25 am, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Well finally I was not sleepy yet, so I took a look and the problem was VERY
> easy.
> Apparently it's just someone at sun who forgot to transfer the lookup
> operation to the table of operations for symlinks. This is one of the rare
> things which is easy to do on the zfs source (like adding new compression
> methods !).
>
> Anyway xattrs on symlinks work again now, and so I removed my previous
> patch.
>
> 2011/8/18 Emmanuel Anne <emmanuel.a...@gmail.com>
Does it also works on symlinks in the sense that symlinks have their
own xattrs? (XATTR_NOFOLLOW support)
~Hannes
On Aug 19, 12:25 am, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Well finally I was not sleepy yet, so I took a look and the problem was VERY
> easy.
> Apparently it's just someone at sun who forgot to transfer the lookup
> operation to the table of operations for symlinks. This is one of the rare
> things which is easy to do on the zfs source (like adding new compression
> methods !).
>
> Anyway xattrs on symlinks work again now, and so I removed my previous
> patch.
>
>
>
>
>
>
>
>
>
>
> > Yes it's a strange story, it didn't work this way before, I wonder what
> > they did with symlinks. Well I'll need more time to look at that, I'll try
> > to take a look tomorrow...
>
> > 2011/8/18 Hannes Landeholm <landeh...@gmail.com>
>
>
>
>
>
>
>
>
> > Yes it's a strange story, it didn't work this way before, I wonder what
> > they did with symlinks. Well I'll need more time to look at that, I'll try
> > to take a look tomorrow...
>
>
> >> By the way, my main problem is really that ZFS does not support xattr
> >> on symlinks at all. This is the related bug for the zfs kernel
> >> project:
>
> >>https://github.com/zfsonlinux/zfs/issues/272
>
> >> It's a small issue which makes it incompatible to run a ZFS + gluster
> >> stack. Is it possible to make a workaround for this in zfs-fuse so the
> >> sun code actually stores xattr's for symlinks instead of returning
> >> ENOSYS?
>
> >> Here is another related link:
>
> >>http://download.gluster.com/pub/gluster/glusterfs/doc/solaris-related...
> >> By the way, my main problem is really that ZFS does not support xattr
> >> on symlinks at all. This is the related bug for the zfs kernel
> >> project:
>
> >>https://github.com/zfsonlinux/zfs/issues/272
>
> >> It's a small issue which makes it incompatible to run a ZFS + gluster
> >> stack. Is it possible to make a workaround for this in zfs-fuse so the
> >> sun code actually stores xattr's for symlinks instead of returning
> >> ENOSYS?
>
> >> Here is another related link:
>
Seth Heeren
Aug 19, 2011, 2:59:24 AM8/19/11
to zfs-fuse
Good work. Thanks a lot! I will integrate this. Probably just into
testing, but if the patch is isolatable and non-intrusive also into
maint.
Cheers,
Seth
On 19 aug, 00:25, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Well finally I was not sleepy yet, so I took a look and the problem was VERY
> easy.
> Apparently it's just someone at sun who forgot to transfer the lookup
> operation to the table of operations for symlinks. This is one of the rare
> things which is easy to do on the zfs source (like adding new compression
> methods !).
>
> Anyway xattrs on symlinks work again now, and so I removed my previous
> patch.
>
> 2011/8/18 Emmanuel Anne <emmanuel.a...@gmail.com>
testing, but if the patch is isolatable and non-intrusive also into
maint.
Cheers,
Seth
On 19 aug, 00:25, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Well finally I was not sleepy yet, so I took a look and the problem was VERY
> easy.
> Apparently it's just someone at sun who forgot to transfer the lookup
> operation to the table of operations for symlinks. This is one of the rare
> things which is easy to do on the zfs source (like adding new compression
> methods !).
>
> Anyway xattrs on symlinks work again now, and so I removed my previous
> patch.
>
>
>
>
>
>
> > Yes it's a strange story, it didn't work this way before, I wonder what
> > they did with symlinks. Well I'll need more time to look at that, I'll try
> > to take a look tomorrow...
>
> > 2011/8/18 Hannes Landeholm <landeh...@gmail.com>
>
>
>
>
> > Yes it's a strange story, it didn't work this way before, I wonder what
> > they did with symlinks. Well I'll need more time to look at that, I'll try
> > to take a look tomorrow...
>
>
> >> By the way, my main problem is really that ZFS does not support xattr
> >> on symlinks at all. This is the related bug for the zfs kernel
> >> project:
>
> >>https://github.com/zfsonlinux/zfs/issues/272
>
> >> It's a small issue which makes it incompatible to run a ZFS + gluster
> >> stack. Is it possible to make a workaround for this in zfs-fuse so the
> >> sun code actually stores xattr's for symlinks instead of returning
> >> ENOSYS?
>
> >> Here is another related link:
>
> >>http://download.gluster.com/pub/gluster/glusterfs/doc/solaris-related...
> >> By the way, my main problem is really that ZFS does not support xattr
> >> on symlinks at all. This is the related bug for the zfs kernel
> >> project:
>
> >>https://github.com/zfsonlinux/zfs/issues/272
>
> >> It's a small issue which makes it incompatible to run a ZFS + gluster
> >> stack. Is it possible to make a workaround for this in zfs-fuse so the
> >> sun code actually stores xattr's for symlinks instead of returning
> >> ENOSYS?
>
> >> Here is another related link:
>
Emmanuel Anne
Aug 19, 2011, 3:00:17 AM8/19/11
to zfs-...@googlegroups.com
Yes, it works on the symlinks themselves, not their target.
2011/8/19 Hannes Landeholm <land...@gmail.com>
To visit our Web site, click on http://zfs-fuse.net/
Seth Heeren
Aug 19, 2011, 3:01:25 AM8/19/11
to zfs-fuse
I'm sure our posts had crossed. That fix is already in the PPA, as I
mentioned in my earlier reply in this thread (it might be google that
sometimes delays posts)
mentioned in my earlier reply in this thread (it might be google that
sometimes delays posts)
Hannes Landeholm
Aug 19, 2011, 7:10:08 AM8/19/11
to zfs-fuse
Can I get a deb after you have integrated it? Would be nice to test it
today.
~Hannes
today.
~Hannes
Seth Heeren
Aug 19, 2011, 10:23:42 AM8/19/11
to zfs-fuse
It's /in the oven/ --> https://launchpad.net/~bugs-sehe/+archive/zfs-fuse/+builds?build_state=pending
I sure hope you don't want the 64bit deb because it says it's 23 hours
till dequeuing.
Cheers
I sure hope you don't want the 64bit deb because it says it's 23 hours
till dequeuing.
Cheers
Seth Heeren
Aug 19, 2011, 10:56:59 AM8/19/11
to zfs-fuse
Hey, I built some myself, in case the wait was going to be very long
with the launchpad build bots:
http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46_i386.deb
http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46_amd64.deb
$0.02 (always prefer the launchpad builds, of course)
with the launchpad build bots:
http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46_i386.deb
http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46_amd64.deb
$0.02 (always prefer the launchpad builds, of course)
Hannes Landeholm
Aug 19, 2011, 11:17:24 AM8/19/11
to zfs-fuse
Sweet, thanks!
~Hannes
On Aug 19, 4:56 pm, Seth Heeren <sghee...@hotmail.com> wrote:
> Hey, I built some myself, in case the wait was going to be very long
> with the launchpad build bots:
>
> http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46...
>
> http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46...
~Hannes
On Aug 19, 4:56 pm, Seth Heeren <sghee...@hotmail.com> wrote:
> Hey, I built some myself, in case the wait was going to be very long
> with the launchpad build bots:
>
>
> http://downloads.sehe.nl/zfs-fuse/zfs-fuse_0.7.0-1ubuntu1~2.gbp43db46...
Reply all
Reply to author
Forward
0 new messages