ReSync with current OpenSolaris zfs sources

[vvatashki]

Hi there,
I did resync with current OpenSolaris zfs sources, you can download
and try it from http://sites.google.com/site/vvatashki/
I've attached the new solaris sources and zfs-fuse.I just applied
Ricardo's patches,I don't know if this is enough for stable zfs-fuse
work.It is BETA release, I'm currently doing some stress testing.So
far so good. This brings us to pool version 16 ( zpool upgrade -v ),
lets test it.

Venci Vatashki

[Ricardo M. Correia]

Hi vvatashki,

Very cool! I'm glad someone has come forward and decided to do some
serious work on zfs-fuse :)

I haven't looked at your code, but I have a few quick tips for you.

I have attached a couple of scripts which I use to update the ZFS
sources from the OpenSolaris mercurial repository into the zfs-fuse
tree.

copysolaris.sh copies the ZFS sources and then calls "fixfiles.py" to
fix the sources files, to remove any "#pragma ident" and "#pragma
rarely_called" lines, which the Linux gcc doesn't like. It also removes
comments from the assembly source code, because the Linux GNU assembler
doesn't like them either.

What I usually do to update the source code is copy all the pristine
source files from OpenSolaris into the "upstream" mercurial repository,
and then merge it with the zfs-fuse repository.

Also, in your web page, you say this:

"Currently I'm examining the efforts needed to port Sun's zfs test suite
to Linux, because it will be a wonderful comparison to the Sun original
and the missing features at Linux. You can find me in zfs-fuse group."

Pawel Jakub Dawidek, who ported ZFS to FreeBSD, was also looking into
this but due to the difficulty in porting, I think he just gave up and
decided to create his own ZFS test suite.

I have taken Pawel's ZFS test suite and ported it to Linux (and to
Solaris).

You can find it in the "tests/regression" directory of the "zfs-lustre"
mercurial repository, which can be found here:
http://www.wizy.org/mercurial/

These tests should work fine with zfs-fuse (just try running "prove
-r ."). You may want to use the "cleanup.sh" script afterwards.

BTW, zfs-fuse is known to fail a few of these tests, specifically some
related to mount/umount, due to some FUSE complications. I haven't
looked into this recently.

Hope that helps,
Ricardo

[Ricardo M. Correia]

On Ter, 2009-06-16 at 20:43 +0100, Ricardo M. Correia wrote:
> I have taken Pawel's ZFS test suite and ported it to Linux (and to
> Solaris).
>
> You can find it in the "tests/regression" directory of the "zfs-lustre"
> mercurial repository, which can be found here:
> http://www.wizy.org/mercurial/
>
> These tests should work fine with zfs-fuse (just try running "prove
> -r ."). You may want to use the "cleanup.sh" script afterwards.

Oh, I forgot to mention: before running the tests you need to run the
'setup.sh' script in zfs-lustre, to apply some patches.

Cheers,
Ricardo

[David Abrahams]

Awesome! Great to know I'll be able to use my OpenSolaris ZFS pools
with Linux if need be.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[vvatashki]

Hi Ricardo
I'm happy to hear from you.Thanks for the work done, zfs is cool
thing.This is my first ever public upload :)

On Jun 16, 10:43 pm, "Ricardo M. Correia" <Ricardo.M.Corr...@Sun.COM>
wrote:

> Hi vvatashki,
>
> On Ter, 2009-06-16 at 12:14 -0700, vvatashki wrote:
>
> > Hi there,
> > I did resync with current OpenSolaris zfs sources, you can download

> > and try it fromhttp://sites.google.com/site/vvatashki/

> > I've attached the new solaris sources and zfs-fuse.I just applied
> > Ricardo's patches,I don't know if this is enough for stable zfs-fuse
> > work.It is BETA release, I'm currently doing some stress testing.So
> > far so good. This brings us to pool version 16 ( zpool upgrade -v ),
> > lets test it.
>
> Very cool! I'm glad someone has come forward and decided to do some
> serious work on zfs-fuse :)
>
> I haven't looked at your code, but I have a few quick tips for you.
>
> I have attached a couple of scripts which I use to update the ZFS
> sources from the OpenSolaris mercurial repository into the zfs-fuse
> tree.

Does Sun have repositories other than OpenGrok ? I've searched for
each file in OpenGrok site,
and downloaded it separately,I dont think that was the smartest way to
do it :)

>
> copysolaris.sh copies the ZFS sources and then calls "fixfiles.py" to
> fix the sources files, to remove any "#pragma ident" and "#pragma
> rarely_called" lines, which the Linux gcc doesn't like. It also removes
> comments from the assembly source code, because the Linux GNU assembler
> doesn't like them either.

I did perl script for that, I'm in perl's army :)

>
> What I usually do to update the source code is copy all the pristine
> source files from OpenSolaris into the "upstream" mercurial repository,
> and then merge it with the zfs-fuse repository.
>

Yes I made a patch file between your "trunk" repository and "upstream"
and applied it to the new sources.
Basicaly this release is your work + new upstream sources + fix for
any compile errors.
I was really helpful to have original sources, so I uploaded current
zfs sources also.I was amazed from the power of patch and diff.

> Also, in your web page, you say this:
>
> "Currently I'm examining the efforts needed to port Sun's zfs test suite
> to Linux, because it will be a wonderful comparison to the Sun original
> and the missing features at Linux. You can find me in zfs-fuse group."
>
> Pawel Jakub Dawidek, who ported ZFS to FreeBSD, was also looking into
> this but due to the difficulty in porting, I think he just gave up and
> decided to create his own ZFS test suite.
>
> I have taken Pawel's ZFS test suite and ported it to Linux (and to
> Solaris).
>
> You can find it in the "tests/regression" directory of the "zfs-lustre"
> mercurial repository, which can be found here:http://www.wizy.org/mercurial/
>
> These tests should work fine with zfs-fuse (just try running "prove
> -r ."). You may want to use the "cleanup.sh" script afterwards.

Thanks, I didn't know for these regression test, I will play with
them.I wanted to stress ZFS filesystem
before I trust it enough to hold my files. I have 3 disk raidz, I did
some plug/unplug tests to disks from the array, It is really cool
watching the resilver :)

>
> BTW, zfs-fuse is known to fail a few of these tests, specifically some
> related to mount/umount, due to some FUSE complications. I haven't
> looked into this recently.
>
> Hope that helps,
> Ricardo
>

This month there is LinuxTag in Berlin, are you going ?

Thanks,
Venci

[Ricardo M. Correia]

On Qui, 2009-06-18 at 10:31 -0700, vvatashki wrote:
> Hi Ricardo
> I'm happy to hear from you.Thanks for the work done, zfs is cool
> thing.This is my first ever public upload :)

Cool :)

> Does Sun have repositories other than OpenGrok ? I've searched for
> each file in OpenGrok site,
> and downloaded it separately,I dont think that was the smartest way to
> do it :)

Yes.. ;) If you go to http://www.opensolaris.org you will find a link
"Get the Source" in the left menu, under "Quick Links".

It has instructions to clone the Mercurial repository :) Using the
Mercurial repo will save you a lot of time, of course :)

> > copysolaris.sh copies the ZFS sources and then calls "fixfiles.py" to
> > fix the sources files, to remove any "#pragma ident" and "#pragma
> > rarely_called" lines, which the Linux gcc doesn't like. It also removes
> > comments from the assembly source code, because the Linux GNU assembler
> > doesn't like them either.
>
> I did perl script for that, I'm in perl's army :)

Cool :) My python for removing the comments is incredibly bad, I bet it
could be done in 10 times fewer lines of code :p

> > What I usually do to update the source code is copy all the pristine
> > source files from OpenSolaris into the "upstream" mercurial repository,
> > and then merge it with the zfs-fuse repository.
> >
>
> Yes I made a patch file between your "trunk" repository and "upstream"
> and applied it to the new sources.

Great, that should work well.

> Basicaly this release is your work + new upstream sources + fix for
> any compile errors.
> I was really helpful to have original sources, so I uploaded current
> zfs sources also.I was amazed from the power of patch and diff.

You'd be even more amazed at the power of the 3-way Mercurial merge,
especially coupled with kdiff3 ;) This could save you additional time,
but simple diff and patch is not a bad choice either.

> This month there is LinuxTag in Berlin, are you going ?

Unfortunately, no.. At the moment I don't have any "appearance at public
gatherings" (lol..) scheduled for the near future, but if you happen to
stop by Lisbon (or possibly Madrid), let me know ;)

Cheers,
Ricardo

[eper]

I can not seem to compile this on my gentoo build box. Any advice
would be helpful. The fuse 0.5.0 code compiles without errors on this
server.

pastebin: http://pastebin.com/m6149b331

cc -Ilib/libsolcompat/include -Ilib/libsolcompat/include/i386 -c -o
lib/libsolcompat/i386/atomic.o lib/libsolcompat/i386/atomic.S
lib/libsolcompat/i386/atomic.S: Assembler messages:
lib/libsolcompat/i386/atomic.S:82: Error: invalid character '=' in
operand 2

angel src # getconf GNU_LIBPTHREAD_VERSION
NPTL 2.9
angel src # /lib/libc.so.6
GNU C Library stable release version 2.9, by Roland McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux >>2.6.18-xen-r12<< system on 2009-06-28.
Available extensions:
C stubs add-on version 2.1.2
crypt add-on version 2.1 by Michael Glad and others
Gentoo snapshot 20081201
Gentoo patchset 5
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc
core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
angel src # gcc --version
gcc (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

angel src # uname -a
Linux angel 2.6.18-xen-r12 #1 SMP Mon Mar 30 20:57:26 GMT 2009 i686
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
angel src #

[vvatashki]

Hi there,
Just overwrite lib/libsolcompat/i386/atomic.S with fuse 0.5.0 version.
Sorry about that, I'm on amd64 arch.

[Emmanuel Anne]

Hi !

I just tried your resync with the experimental fuse-2.8.0-pre2 "long
writes" patches, and it doesn't work at all. I could fix a 1st crash
in what looked like a nfs optimization, but it still crashes more
rarely in vn_rele_async.

So I wanted to know your thoughts about this :
- is this "long writes" patch usefull with all your optimizations
already in place ?
- do the crashes come from the beta fuse version ?
- do you still work on the code ? ;-)

Anyway I have reverted to your original version and fuse stable 2.7.4
for now...

On 16 juin, 21:14, vvatashki <vvatas...@gmail.com> wrote:
> Hi there,
> I did resync with current OpenSolaris zfs sources, you can download

> and try it fromhttp://sites.google.com/site/vvatashki/

[sghe...@hotmail.com]

What patch are you referring to? "long writes" doesn't mean anything to
me and it's the first time I've heard it mentioned on this list.

I'm assuming you mean "big_writes" which is not as much a zfs patch as
well as a new fuse option. It's operation should be automatic (and
transparent to zfs-fuse) once you specifiy the option to zfs-fuse. For
pragmatic reasons, the option still is to be hardcoded in a source
file... which is why it 'appears' to be a patch.

It really is more like a config option.

So I'm curious whether you are referring to this or a different ('real')
patch. Both could be interesting.

Regards

[Emmanuel Anne]

2009/7/8 sghe...@hotmail.com <sghe...@hotmail.com>

What patch are you referring to? "long writes" doesn't mean anything to
me and it's the first time I've heard it mentioned on this list.

Yeah sorry I thought you might say that just after sending the mail.
I was referring to this :

" You _might_ have to use the latest pre-release (which is actually quite
well tested with zfs-fuse due to some interesting performance benefits:
see http://techarcana.net/hydra/zfs-installation/ (installing an updated
fuse). This article was written by Dave Abrahams, who also frequents
this list."

And it was "big writes", not long writes sorry.

I'm assuming you mean "big_writes" which is not as much a zfs patch as
well as a new fuse option. It's operation should be automatic (and
transparent to zfs-fuse) once you specifiy the option to zfs-fuse. For
pragmatic reasons, the option still is to be hardcoded in a source
file... which is why it 'appears' to be a patch.

It really is more like a config option.

So I'm curious whether you are referring to this or a different ('real')
patch. Both could be interesting.

Ok, so it might just be because I didn't do a "make clean" and I might have mixed objects files from the old libfuse and from the new one then.

And I am curious to know if it's worth the trouble installing the beta version of fuse then ?

[sghe...@hotmail.com]

Emmanuel Anne wrote:
> Ok, so it might just be because I didn't do a "make clean" and I might
> have mixed objects files from the old libfuse and from the new one then.

This could easily be the case. On my system I use apt-get to remove all
fuse - related items (I just got rid of my backup package list for that,
sorry), and zfs-fuse.

Then I proceed to build fuse & zfs-fuse from sources. I make sure
(updatedb; mlocate zfs) there are no leftovers of other versions.

> And I am curious to know if it's worth the trouble installing the beta
> version of fuse then ?

As far as I've heard there's only one way to find out: try it (and
measure it). As far as this list is concerned (if I didn't miss any
posts?) no-one is running that configuration yet. In fact, people are
not very quick to report any luck with the new zfs-fuse version at all.
Me included :)
>
>
> Regards
>
> Emmanuel Anne wrote:
>

[Emmanuel Anne]

2009/7/8 sghe...@hotmail.com <sghe...@hotmail.com>

> And I am curious to know if it's worth the trouble installing the beta
> version of fuse then ?

As far as I've heard there's only one way to find out: try it (and
measure it). As far as this list is concerned (if I didn't miss any
posts?) no-one is running that configuration yet. In fact, people are
not very quick to report any luck with the new zfs-fuse version at all.
Me included :)

Well I am currently trying a setup with a mirror on an external hard disk on a 112 Gb partition, and even without the big writes patch it's already very fast (around 2 Gb/minute to resync the mirror, and it syncs only what has changed since the last sync, it's even faster than rsync).
So for now except the crashes I had because of my bad tests with this mor or less experimental branch, it works very well.

I am using your version 16 pool. My only regret is that it's impossible to mount this version 16 with any older version, and mac os x is stuck at version 8, so it makes quite a big difference, but it's not too important.

I am also testing it on my home, enabling compression for most of it,  it's not mirrored yet, but I keep a backup elsewhere in case of unexpected crashes !

Anyway it's very interesting to test actually !

[Rudd-O]

I tested your resync plus the two patches that you provided on the
list. Almost every single dataset I have in my four disks does NOT
APPEAR when doing zfs list or doing zfs mount -a -- only one dataset
appears (internal/home). However, if I do a zfs mount internal/shared
or zfs get all internal/shared, they mount and show the properties,
which means ZFS-FUSE is seeing those datasets.

What's wrong? Why aren't my datasets showing? Until this is
resolved, I do not believe I can confidently move to the newest
version of ZFS that you kindly provided, nor do I believe anyone
should.

And how can I help you debug the issue more effectively? What do you
need from me? I'm running the latest Correia tip, if you need to
know. I can provide the changesets I committed to my private tree,
anything you ask.

Please, halp.

[Rudd-O]

And man, by the way, I was scared ****SHITLESS**** when both my backup
and primary datasets died except for one small dataset.

Here is my dataset list:

/home/rud...@karen.dragonfear Ω:
zfs list
NAME USED AVAIL REFER MOUNTPOINT
external 441G 12,2G 21K /mnt/external
external/backup 350G 12,2G 23K /mnt/external/
backup
external/backup/home 40,2G 12,2G 40,2G /mnt/external/
backup/home
external/backup/root 4,85G 12,2G 4,85G /mnt/external/
backup/root
external/backup/shared 303G 12,2G 26,5K /mnt/external/
backup/shared
external/backup/shared/fun 292G 12,2G 1,36G /mnt/external/
backup/shared/fun
external/backup/shared/fun/movies 13,6G 12,2G 13,6G /mnt/external/
backup/shared/fun/movies
external/backup/shared/fun/music 103G 12,2G 103G /mnt/external/
backup/shared/fun/music
external/backup/shared/fun/tv 174G 12,2G 174G /mnt/external/
backup/shared/fun/tv
external/backup/shared/knowledge 2,15G 12,2G 2,15G /mnt/external/
backup/shared/knowledge
external/backup/shared/software 8,70G 12,2G 8,70G /mnt/external/
backup/shared/software
external/backup/tobey 2,30G 12,2G 2,30G /mnt/external/
backup/tobey
external/lowimportance 90,1G 12,2G 90,1G /mnt/external/
lowimportance
internal 342G 24,0G 18K none
internal/home 40,2G 24,0G 40,2G /home
internal/shared 302G 24,0G 27,5K /var/shared
internal/shared/fun 291G 24,0G 1,30G /var/shared/
Entertainment
internal/shared/fun/movies 13,6G 24,0G 13,6G /var/shared/
Entertainment/Movies
internal/shared/fun/music 103G 24,0G 103G /var/shared/
Entertainment/Music
internal/shared/fun/tv 173G 24,0G 173G /var/shared/
Entertainment/TV
internal/shared/knowledge 2,15G 24,0G 2,15G /var/shared/
Knowledge
internal/shared/software 8,70G 24,0G 8,70G /var/shared/
Software

[Rudd-O]

The Mercurial changeset I did to get these errors has been attached
to

http://groups.google.com/group/zfs-fuse/

there it is.

[Emmanuel Anne]

2009/7/11 Rudd-O <rud...@rudd-o.com>

I tested your resync plus the two patches that you provided on the
list.  Almost every single dataset I have in my four disks does NOT
APPEAR when doing zfs list or doing zfs mount -a -- only one dataset
appears (internal/home).  However, if I do a zfs mount internal/shared
or zfs get all internal/shared, they mount and show the properties,
which means ZFS-FUSE is seeing those datasets.

What's wrong?  Why aren't my datasets showing?  Until this is
resolved, I do not believe I can confidently move to the newest
version of ZFS that you kindly provided, nor do I believe anyone
should.

Ok, slow down here.
1st I don't use zfs mount -a because when I tested this the 1st time it didn't work as I expected so I started to use zpool import -a instead and never looked back (which does what it says, it mounts everything).

So... I have already 2 pools here, 1 containing something like 3 "datasets" (mounted in the same root directory), and the other pool with only 1 filesystem.
Everything is mounted when I use zpool import -a.

So what are you saying ? That in such a case if you export everyting, zfs mount -a should remount everything ? Well I just tried with the binaries from version 0.5.0 and zfs mount -a when everything is exported does nothing at all. So I probably missed something here.

And how can I help you debug the issue more effectively?  What do you
need from me?  I'm running the latest Correia tip, if you need to
know.  I can provide the changesets I committed to my private tree,
anything you ask.

What's this " Correia tip" ? ;-) and while I am at it, I don't know mercurial at all so how do I use your mercurial "changeset" ? (what is there in this file...).

For your problem just give a simple example which can be easily reproduced and it should be possible to fix it (hopefully !).

ps : for your fear to loose data, well don't forget that it's just zfs-fuse which has the bugs so far. All the fixes I have put in the patch so far are trivial. It's more like the people who have maintained this have focused on the kernel side of things and they have mostly forgoten about the user side of things (fuse). So far it's been easy.
And it means also that the worst thing you risk is to see zfs-fuse dying suddenly in the middle of things. In this case you loose the files which were opened for writing + the ones stuck in the cache. Then you relaunch zfs-fuse, export the pools still mounted (because you can't access them anymore in this state), import them again (import -a), and you are good to go. It happened to me a few times before I sent the 1st patch, it tought me how to clean up my ~/.firefox and my ~/.local directories, but except that no trouble at all (it's just frustrating, that's all !).

Using this version might be a little more risky but it's probably also more interesting, at least from my point of view ! ;-)

[Rudd-O]

Okay, seems you haven't understood well or I didn't explain myself
well.

Here is what I did.

- I applied your first "patch". It is rather a tarball, not a patch.
I committed that.
- I applied your first real patch. I committed that.
- I applied your secnod real patch. It didn't apply cleanly but I saw
no egregious errors in the hg diff, so I committed that.
- I applied my performance enhancement patch. It didn't seem to apply
clearly because you seem to have merged it earlier into one big thing
there. But the code was sound so okay, compile.
- I copied the bins to a temporary folder in /
- I telinited 1
- I zfs unmount -a
- I killall -TERM zfs-fuse
- I replaced the zfs-fuse binaries, backing up the old ones
- I started the new zfs-fuse
- I saw with zfs list that my datasets were GONE except for one
- I saw with zpool list that my zpools were there and they had the
space allocated
- I zfs mount -a and there it was, the only dataset that ZFS detected
was there , mounted, but the other datasets weren't there
- I zfs mount external/shared to see if that dataset was there but
"hidden". In effect, it mounted correctly!
- After that, I was just too plain scared to continue so I basically
nuked your code and reverted to my old binaries

I don't know what is it that you're talking about zpool import -- that
command plays NO ROLE here because I'm not importing pools that were
exported previously. I have never had to *export* any zpool before
upgrading ZFS and reimport the zpools afterwards -- and I don't see
why I should start now, and risk the new ZFS writing something to disk
that will obliterate the pools inside it.

There HAS TO BE a bug in the code that you committed.

Correia's tip is the last commit in mercurial. The changeset I
applied and published here is nothing more than a sequential list of
commits that apply on top of Correia's tip. Read the hg manpage to
understand more about hg -- you will find it very valuable.

As for the bug, I definitely don't want to export my datasets with my
current ZFS, and reimport with your ZFS -- exporting and importing
actually *write* stuff to disk, and I don't feel like losing 1.2 TB of
data by experimenting with code that has such a scary bug. Losing 1.2
TB of data is not my version of "a *little* more risky" -- in fact,
"little" is the understatement of the year.

[Rudd-O]

Another thing: you really need to start working with version control.

[Rudd-O]

I re-did the changesets and I'm about to post them now. No change,
same problem.

HOWEVER.

I think I have a hypothesis.

Your new code is somehow iterating wrongly through the datasets /
zvols, ignoring every other dataset. I know this because when I
export one of my datasets (and leave only one imported) zpool reports
that the other remaining pool (which showed one dataset earlier) now
shows no datasets. Couple that with the fact that I can get the
properties of a dataset with zfs get all name/of/dataset, whether it
shows up or not, and you have an easier bug to correct.

[Emmanuel Anne]

2009/7/11 Rudd-O <rud...@rudd-o.com>

Okay, seems you haven't understood well or I didn't explain myself
well.

Here is what I did.

- I applied your first "patch".  It is rather a tarball, not a patch.
I committed that.

Actually I was not the one who posted the tarball, I just happened to actually use it for real work, and so I started to patch it since it didn't work very well.

- I applied your first real patch.  I committed that.
- I applied your secnod real patch.  It didn't apply cleanly but I saw
no egregious errors in the hg diff, so I committed that.

It was supposed to be applied on the tarball. Same principle as the kernel patches, they don't apply on each other or in the end you have a nameless mess...

- I applied my performance enhancement patch.  It didn't seem to apply
clearly because you seem to have merged it earlier into one big thing
there.  But the code was sound so okay, compile.

Yeah is there a public svn / git / mercurial or anything somewhere to centralize all this ?

- I copied the bins to a temporary folder in /
- I telinited 1
- I zfs unmount -a
- I killall -TERM zfs-fuse
- I replaced the zfs-fuse binaries, backing up the old ones
- I started the new zfs-fuse
- I saw with zfs list that my datasets were GONE except for one
- I saw with zpool list that my zpools were there and they had the
space allocated
- I zfs mount -a and there it was, the only dataset that ZFS detected
was there , mounted, but the other datasets weren't there
- I zfs mount external/shared to see if that dataset was there but
"hidden".  In effect, it mounted correctly!
- After that, I was just too plain scared to continue so I basically
nuked your code and reverted to my old binaries

I don't know what is it that you're talking about zpool import -- that

command plays NO ROLE here because I'm not importing pools that were
exported previously.  I have never had to *export* any zpool before
upgrading ZFS and reimport the zpools afterwards -- and I don't see
why I should start now, and risk the new ZFS writing something to disk
that will obliterate the pools inside it.

Oh no, pools are very stable, they get upgraded only if you use upgrade, a simple import won't change them. Well there was probably a bug in this version with zfs mount from the start so on my side I just changed the zfs-fuse start script to use zpool import -a and a few lines to export them one by one instead of zfs mount -a and zfs umount -a, it works well too.

I guess I need to do a few checks on zfs mount then.

There HAS TO BE a bug in the code that you committed.

Hehe, I didn't commit anything actually, the bug was probably in the tar ball from the start ! ;-)

Correia's tip is the last commit in mercurial.  The changeset I
applied and published here is nothing more than a sequential list of
commits that apply on top of Correia's tip.  Read the hg manpage to
understand more about hg -- you will find it very valuable.

As for the bug, I definitely don't want to export my datasets with my
current ZFS, and reimport with your ZFS -- exporting and importing
actually *write* stuff to disk, and I don't feel like losing 1.2 TB of
data by experimenting with code that has such a scary bug.  Losing 1.2
TB of data is not my version of "a *little* more risky" -- in fact,
"little" is the understatement of the year.

Lol, ok no problem.
But the reason why I started to use zfs from the start is that it's very carefull with its data (there is even an option to import a pool you just destroyed !). But on my side all my pools are either mirrored or backup so it's much less risky here, ok no problem, I will try to find out what happened with this zfs mount.

[Emmanuel Anne]

Well after some testing, I can't reproduce your problem, the standard script which uses zfs mount -a / zfs umount -a now works correctly.

I even did some testing by using the 0.5.0 binaries to create some test images :

mkdir /root/dd
cd /root/dd
dd if=/dev/zero of=image bs=1024 count=102400
dd if=/dev/zero of=image2 bs=1024 count=102400
zpool create test /root/image
zfs create test/1
zfs create test/2
zfs create test/3
zpool create test2 /root/image2
zfs create test/4
zfs create test/5
zfs create test/6

after all this I unmounted everything by running
/etc/init.d/zfs-fuse stop

replaced the binaries by those for the version 16 pools (the most recent ones), and rebooted.
After the boot, the zfs mount -a correctly remounted my version 16 pools + all the test datasets created with the old binaries, so I don't see what I can do to help you here...

manu@athlon64:~% sudo zpool status
[sudo] password for manu:
  pool: home
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        home        ONLINE       0     0     0
          sda9      ONLINE       0     0     0

errors: No known data errors

  pool: test
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
config:

        NAME              STATE     READ WRITE CKSUM
        test              ONLINE       0     0     0
          /root/dd/image  ONLINE       0     0     0

manu@athlon64:~% sudo zfs list

NAME                USED  AVAIL  REFER  MOUNTPOINT

home               16,2G  10,9G  3,46G  /home
home/manu          2,69G  10,9G  2,66G  /home/manu
home/manu/Desktop  36,2M  10,9G  36,2M  /home/manu/Desktop
test                148K  63,4M    22K  /test
test/1               18K  63,4M    18K  /test/1
test/2               18K  63,4M    18K  /test/2
test/3               18K  63,4M    18K  /test/3
test2               148K  63,4M    22K  /test2
test2/4              18K  63,4M    18K  /test2/4
test2/5              18K  63,4M    18K  /test2/5
test2/6              18K  63,4M    18K  /test2/6
zip1               57,0G  57,2G  57,0G  /zip1

2009/7/11 Rudd-O <rud...@rudd-o.com>

[Rudd-O]

OK then, it appears that the bug is in the zfs command, either in
zfs_main.c or in zfs_iter.c, because they seem to be iteration bugs
(in other words they appear to work fine with only one pool and
dataset, but if you have more, somehow the even ones get skipped on
both listing and mounting).

About the version control thing -- use hg locally for your changes. I
have taken the time to create a changeset that you can easily apply on
top of Ricardo's hg checkout, so check it out, and then apply my
changeset. There is no need for a central commit location -- you can
upload your own hg tree anywhere in the Web and push changesets in
there, and we can go back and forth with that.

I've set up a project tracking where you can clone my work and track
it closely, and you can also share changesets with me using that. The
down-to-earth is that you hg clone from my repo, work on that, hg
commit every chagne, and then you can do hg bundle to send me that
file and I can incorporate.

http://rudd-o.com/new-projects/zfs

[Rudd-O]

Ship me your tarball via email or post it here, so I can diff and see
whether my tree is different to yours, and in that case, how.

Please.

[Rudd-O]

I have now published a nice browsable Mercurial repo that you should
be able to clone from, in the address of the project I showed now.

[Emmanuel Anne]

Ok, I'll take a look at the mercurial repositaries then.
For the tarball, I'll wait a little, because I had an expected return of the crash last night, still the same error :

lib/libsolkerncompat/vnode.c:670: vn_rele_async: Assertion `taskq_dispatch(taskq
, (task_func_t *)vn_rele_inactive, vp, TQ_SLEEP) != 0` failed.

So it means either that this particular vn_rele_async:doesn't work as expected, or that the value I have put here is  still not enough (12). From the 1st tests, it seems to work normally, the allocations are done and used, they don't increase all the time. So I have increased to 14 (like what there is for system_taskq), and I'll test some more.
(I talk about the taskq_create call in lib/libzpool/dsl_pool.c, I had fixed tq_maxalloc with 12 in my current patch).

This particular error is very hard to reproduce, I don't even know how to do it, I just use the filesystems, hoping that something will eventually go wrong.
So I nedd a little more time to see all this in more detail...

2009/7/12 Rudd-O <rud...@rudd-o.com>

[Rudd-O]

The tarball published by Venci Vatashki here corresponds to:

http://git.rudd-o.com/zfs/rev/ec280fdbc0b0

in my mercurial repo.

[eper]

I have tried http://git.rudd-o.com/zfs/rev/ec280fdbc0b0 but not
having any luck on a 32bit system.

Linux angel 2.6.29-gentoo-r5 #1 SMP Wed Jul 15 08:35:26 GMT 2009 i686

AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux

Tried fuse-2.8.0-pre3 and fuse-2.7.4.

Tried also with a 2.6.24 kernel and same problems.

angel lib # zpool import tank
cannot import 'tank': invalid vdev configuration
angel lib # zpool import
pool: tank
id: 5102661336201720356
state: UNAVAIL
action: The pool cannot be imported due to damaged devices or data.
config:

tank UNAVAIL insufficient replicas
raidz1 UNAVAIL corrupted data
sdb ONLINE
sde ONLINE
sdd ONLINE
sdc ONLINE
angel lib #

If I reboot back to opensolaris they import fine and export without
problems.

The strange thing also is dmesg outputs 'end_request: I/O error, dev
fd0, sector 0' every time I try and import the pool.

[sghe...@hotmail.com]

Does anyone have a place set-up where we can coordinate this.

A wiki, *bug tracker* (very important), and perhaps repo browser would be nice. A forum would be ok, though in my view this list could still manage the load if the technical details went to a wiki/bug tracker.

As it stands we have one complicated thread going, mixing multiple bug reports, alpha tests of various (unlabeled) HG revisions, inline output of commands, general discussion on version management and different feature(s)/requests... I'll try to attach the graph images inline for illustration (I'm afraid googlegroups will detach the attachments...)



I'd be happy to set something up myself, but I'd prefer it if it were somewhere 'open' and 'free' (gitorious, googlecode, where is the rest hosting their stuff); especially: community 'owned'. I own a few servers that could be used but then again, what happens if I get hit by a bus.

I'll say it again (I have been jubilating to others): I think it is great that the zfs-fuse list runs into the luxury problem of not scaling too well :)
If someone knows a place to be hosted (perhaps it exists already) then I'd be happy to put in some work to get it setup.

Regards,
Seth


eper wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To post to this group, send email to zfs-...@googlegroups.com
To unsubscribe from this group, send email to zfs-fuse+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/zfs-fuse?hl=en
-~----------~----~----~----~------~----~------~--~---



  

[Emmanuel Anne]

2009/7/15 eper <eper...@gmail.com>

I have tried  http://git.rudd-o.com/zfs/rev/ec280fdbc0b0 but not
having any luck on a 32bit system.

Linux angel 2.6.29-gentoo-r5 #1 SMP Wed Jul 15 08:35:26 GMT 2009 i686
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux

Tried fuse-2.8.0-pre3 and fuse-2.7.4.

Tried also with a 2.6.24 kernel and same problems.

angel lib # zpool import tank
cannot import 'tank': invalid vdev configuration
angel lib # zpool import
 pool: tank
   id: 5102661336201720356
 state: UNAVAIL
action: The pool cannot be imported due to damaged devices or data.
config:

       tank        UNAVAIL  insufficient replicas
         raidz1    UNAVAIL  corrupted data
           sdb     ONLINE
           sde     ONLINE
           sdd     ONLINE
           sdc     ONLINE
angel lib #

If I reboot back to opensolaris they import fine and export without
problems.

On my side I never succeeded to import in opensolaris any zfs pool created in linux, but it seems mainly because I used extended partitions or external usb drives and it seems to have troubles to access the partition.

Did you try to export the pool first (if it's possible !). Try at least to export it with a zfs version which can import it, and then to import it with the new version. I have read somewhere that pools created with opensolaris need to be exported first to be mountable in linux (don't remember where).

For the 32-bit version, I have just tried to compile this on a 32-bit laptop and I can confirm it seems to work with the debian compilation patch commited (I'll post in the other thread for that). But I couldn't import my mirror because it detected it's in use by another machine, and since I don't want to restart the mirror from scratch I didn't force the import.

The strange thing also is dmesg outputs 'end_request: I/O error, dev
fd0, sector 0' every time I try and import the pool.

Yeah probably normal, if it doesn't kinow where to find the pool you are trying to import it is trying all the block devices it can find in /dev. So if you have a floppy, it tries the floppy too !

[Emmanuel Anne]

I vote yes for a bug tracker if there is not already 1 somewhere...
Nice colors too ! ;-)

2009/7/15 sghe...@hotmail.com <sghe...@hotmail.com>

[Emmanuel Anne]

 I just managed to create some volumes from opensolaris on a fat32 partition (!), I created a raidz1, + a normal 1 image volume, and they imported without problem in linux. Tested with a 64 bit system...

(and I noticed that opensolaris, the version on the live cd, still uses pools version 14 so it can't import the ones I create in linux !!!).

So I am lost here...

2009/7/15 Emmanuel Anne <emmanu...@gmail.com>

[dev...@web.de]

>I vote yes for a bug tracker if there is not already 1 somewhere...

there already is one at http://developer.berlios.de/bugs/?group_id=6836

> Nice colors too ! ;-)
>
> 2009/7/15 sghe...@hotmail.com<sghe...@hotmail.com>
>
> Does anyone have a place set-up where we can coordinate this.
>
> A wiki, *bug tracker* (very important), and perhaps repo browser
> would be nice. A forum would be ok, though in my view this list could
> still manage the load if the technical details went to a wiki/bug
> tracker.
>
> As it stands we have one complicated thread going, mixing multiple
> bug reports, alpha tests of various (unlabeled) HG revisions, inline
> output of commands, general discussion on version management and
> different feature(s)/requests... I'll try to attach the graph images
> inline for illustration (I'm afraid googlegroups will detach the
> attachments...)
>

> I'd be happy to set something up myself, but I'd prefer it if it were
> somewhere 'open' and 'free' (gitorious, googlecode, where is the rest
> hosting their stuff); especially: community 'owned'. I own a few
> servers that could be used but then again, what happens if I get hit
> by a bus.
>
> I'll say it again (I have been jubilating to others): I think it is
> great that the zfs-fuse list runs into the luxury problem of not
> scaling too well :)
> If someone knows a place to be hosted (perhaps it exists already)
> then I'd be happy to put in some work to get it setup.
>
> Regards,
> Seth
>

> eper wrote:I have tried http://git.rudd-o.com/zfs/rev/ec280fdbc0b0

> but not having any luck on a 32bit system. Linux angel 2.6.29-gentoo-
> r5 #1 SMP Wed Jul 15 08:35:26 GMT 2009 i686 AMD Athlon(tm) 64 X2 Dual
> Core Processor 4200+ AuthenticAMD GNU/Linux Tried fuse-2.8.0-pre3 and
> fuse-2.7.4. Tried also with a 2.6.24 kernel and same problems. angel
> lib # zpool import tank cannot import 'tank': invalid vdev configuratio

> n angel lib # zpool import pool: tank id: 5102661336201720356 state:

> UNAVAIL action: The pool cannot be imported due to damaged devices or
> data. config: tank UNAVAIL insufficient replicas raidz1 UNAVAIL
> corrupted data sdb ONLINE sde ONLINE sdd ONLINE sdc ONLINE angel lib #
> If I reboot back to opensolaris they import fine and export without

> problems. The strange thing also is dmesg outputs 'end_request: I/O
> error, dev fd0, sector 0' every time I try and import the pool. On

> Jul 14, 3:47 am, Rudd-O <rud...@rudd-o.com> wrote: The tarball

> published by Venci Vatashki here corresponds to:http://git.rudd-o.com/
> zfs/rev/ec280fdbc0b0in my mercurial repo. On 12 jul, 12:52, Emmanuel

> Anne <emmanuel.a...@gmail.com> wrote: Ok, I'll take a look at the
> mercurial repositaries then. For the tarball, I'll wait a little,
> because I had an expected return of the crash last night, still the
> same error : lib/libsolkerncompat/vnode.c:670: vn_rele_async:
> Assertion `taskq_dispatch(taskq , (task_func_t *)vn_rele_inactive, vp,
> TQ_SLEEP) != 0` failed. So it means either that this particular vn_
> rele_async:doesn't work as expected, or that the value I have put
> here is still not enough (12). From the 1st tests, it seems to work
> normally, the allocations are done and used, they don't increase all
> the time. So I have increased to 14 (like what there is for system_
> taskq), and I'll test some more. (I talk about the taskq_create call
> in lib/libzpool/dsl_pool.c, I had fixed tq_maxalloc with 12 in my
> current patch). This particular error is very hard to reproduce, I
> don't even know how to do it, I just use the filesystems, hoping that
> something will eventually go wrong. So I nedd a little more time to
> see all this in more detail... 2009/7/12 Rudd-O <rud...@rudd-o.com>I
> have now published a nice browsable Mercurial repo that you should be
> able to clone from, in the address of the project I showed now. On
> Jul 11, 5:33 pm, Rudd-O <rud...@rudd-o.com> wrote: Ship me your
> tarball via email or post it here, so I can diff and see whether my
> tree is different to yours, and in that case, how. Please.
>
> >
>
>

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

[Rudd-O]

I have added new URLs for the BerliOS bug tracker in my site.


But, frankly, the BerliOS BT is really ugly. I can set up a new bug
tracker site and give any of you guys administrative access if you
want, and if someone comes up with a migration path from BerliOS to
Poi, I am glad to accommodate that idea too.

[Rudd-O]

Eper, can you do a poor man's bisect for us? You're the only one that
has this particular problem so your information would be VERY VALUABLE
to us.

More info:

Compile a set of binaries for each revision since the last common
revision between my repository and Correia's repo (which is
http://git.rudd-o.com/zfs/rev/008c531499cd ).

Then run your tests on each set of binaries, from oldest to newest,
and note which revisions have the bug that you discussed, and which
ones doesn't.

Then report to us, pretty please, on this list, or on the berlios
tracker (and then paste us an URL to the bug so we can follow up --
most of us are not subscribed to the bug tracker).

Thank you in advance.

[Ravi Pinjala]

Could it be related to this issue?

http://groups.google.com/group/zfs-fuse/browse_thread/thread/fe4c06dad476d0d/afa9a2c478b1a098

summary: zfs-fuse and Solaris ZFS treat whole disks differently w.r.t.
partitions.

On Jul 15, 4:30 am, eper <eperd...@gmail.com> wrote:
> I have tried  http://git.rudd-o.com/zfs/rev/ec280fdbc0b0but not

[eper]

It is possible this is the case. The ZFS raidz was created on FreeBSD
originally which advises I use the raw device to create the pool, I
then exported it and imported it on Linux ZFS-fuse 0.5.0 which worked
fine. I then tried out Opensolaris and upgraded the raidz to version
16 ? Which broke it working with zfs-fuse 0.5.0. I then found the
vvatashki patches which refused to compile under 32-bit but compiled
fine on the 64bit OS. This worked fine and mounted the raidz pool.

I now have returned to a 32bit OS but with the latest release and it
does the error above. It is strange as in Opensolaris it refuses to
import the pool as it identifies the vdev's incorrectly as
disk0partion8 when I am using the entire disk without a partition
table on. However if I update the symlinks to point it directly to the
raw device rather than the partition it imports them fine.

I think I will try wiping one of the disk's and creating a partition
table then add it back to the pool then letting it resilver and repeat
it for the others so that they get valid disk partitions.

On Jul 16, 6:53 am, Ravi Pinjala <psta...@gmail.com> wrote:
> Could it be related to this issue?
>

> http://groups.google.com/group/zfs-fuse/browse_thread/thread/fe4c06da...

[eper]

This makes no sense to me anymore.

angel ~ # zpool import
pool: tank
id: 5102661336201720356
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

tank ONLINE
raidz1 ONLINE
sde ONLINE
sdc ONLINE
sdb ONLINE
sda ONLINE
angel ~ # uname -a
Linux angel 2.6.29-gentoo-r5 #1 SMP Sun Jun 28 16:34:04 BST 2009
x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/
Linux
angel ~ #

Right so that works fine. I zpool export the pool reboot in to the
32bit kernel and;

angel ~ # zpool import

pool: tank
id: 5102661336201720356
state: UNAVAIL

status: The pool is formatted using an incompatible version.
action: The pool cannot be imported. Access the pool on a system
running newer
software, or recreate the pool from backup.
see: http://www.sun.com/msg/ZFS-8000-A5
config:

tank UNAVAIL newer version
raidz1 ONLINE
sde ONLINE
sdc ONLINE
sdb ONLINE
sda ONLINE

Linux angel 2.6.29-gentoo-r5 #1 SMP Wed Jul 15 08:35:26 GMT 2009 i686
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux

Answers on a postcard please.

[Emmanuel Anne]

Ah ok, now at least we know there is a problem between 32 bit and 64 bits ! ;-)

Well, I hope it's not about whole disk only because it would be difficult to test here on a whole disk... I'll try to make some more comparative tests tomorrow between my 32 bit setup and my 64 bit setup then...

2009/7/16 eper <eper...@gmail.com>

[eper]

Ok I take it all back. It works fine under 32bit/64bit.

It's all down to virtualisation. Running it inside a linux Vmware or
Virtualbox VM causes the problem. The physical disk's are mapped
through fine but it just says the raidz is corrupted every time in
32bit and 64bit VM's. Very strange. Works fine as Virtualbox +
Opensolaris but Virtualbox + Linux = no go and Vmware + Linux = no
go.

Unsure why Opensolaris works fine but Linux does not.

On Jul 16, 10:15 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Ah ok, now at least we know there is a problem between 32 bit and 64 bits !
> ;-)
>
> Well, I hope it's not about whole disk only because it would be difficult to
> test here on a whole disk... I'll try to make some more comparative tests
> tomorrow between my 32 bit setup and my 64 bit setup then...
>

> 2009/7/16 eper <eperd...@gmail.com>

[Jack Sparrow]

On Wed, Jul 15, 2009 at 9:38 PM, Rudd-O<rud...@rudd-o.com> wrote:
> But, frankly, the BerliOS BT is really ugly.  I can set up a new bug
> tracker site and give any of you guys administrative access if you
> want, and if someone comes up with a migration path from BerliOS to
> Poi, I am glad to accommodate that idea too.

I would also be glad to provide any hosting if necessary.