Discussion:
slow start of zfs pool, rebuilding zfs-fuse from git
(too old to reply)
Emmanuel Anne
2012-03-29 21:46:49 UTC
Permalink
Here is the forward of the mail which couldn't reach the google groups for
some reason, and the reply :

1) yes zfs-fuse doesn't like ctrl-c in the middle of these things. Well it
will recover, but it will take time, just be patient, it can take more than
1 hour (i know it's stupid, I don't know if there is a safe way to
interrupt this).

2) Compilation failure is probably because of libc6-dev-2.14 or higher. In
debian testing we still have 2.13, so I'll stick with it for now ! ;-)

---------- Forwarded message ----------
From: Stefan G. Weichinger <lists-5bIVi+***@public.gmane.org>
Date: 2012/3/29
Subject: Fwd: slow start of zfs pool, rebuilding zfs-fuse from git
To: Emmanuel Anne <emmanuel.anne-***@public.gmane.org>



May I be so blunt to simply send it to you personally?

My mails seem not to get through on googlegroups.

pls forgive ...

Greets, Stefan


-------- Original-Nachricht --------
Betreff: slow start of zfs pool, rebuilding zfs-fuse from git
Datum: Wed, 28 Mar 2012 22:19:21 +0200
Von: Stefan G. Weichinger <gmail-0cGGFY0Wf+KzZXS1Dc/***@public.gmane.org>
Antwort an: gmail-0cGGFY0Wf+KzZXS1Dc/***@public.gmane.org
An: zfs-fuse-/***@public.gmane.org


greets ...

following issue today:

I started a send/receive to "convert" a zfs-fs from uncompressed to
compressed.

That was slow ... so I decided to Ctrl-C that ... and issued a "zfs
destroy" on both the source snapshot and the target fs.

For both the system replied "in use" ... so I simply let that aside and
thought that sometimes later that would simply solve itself.

An hour later I decided to reboot the box due to another issue
(DVB-card, kernel-problem) ... after that the box booted up until the
start of the zfs-pool and mounting the zfs file systems.

And there it stood .... for an hour or so .... harddisks heavily working.

Was that to be expected?

I "solved" it by temporarily disconnecting the zfs-hdds, booting,
disabling zfs-fuse ... so that I could use the server again. Now those
fs are gone ...

-

Just to be up to date I tried to re-pull the latest release from
Emmanuel's repo (via my own gentoo-ebuild):


* GIT update -->
* repository: http://rainemu.swishparty.co.uk/git/zfs
* at the commit: bceb29459f83143cade7225efe6771a3091e3bd5
* branch: master


Unfortunately it doesn't compile here:


libtool: link: (cd ".libs" && rm -f "libumem.so.0" && ln -s
"libumem.so.0.0.0" "libumem.so.0")
libtool: link: (cd ".libs" && rm -f "libumem.so" && ln -s
"libumem.so.0.0.0" "libumem.so")
libtool: link: ar cru .libs/libumem.a init_lib.o umem_agent_support.o
umem_fail.o umem_fork.o umem_update_thread.o vmem_mmap.o vmem_sbrk.o
envvar.o getpcstack.o misc.o vmem_base.o umem.o vmem.o
libtool: link: ranlib .libs/libumem.a
libtool: link: ( cd ".libs" && rm -f "libumem.la" && ln -s
"../libumem.la" "libumem.la" )
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-MT malloc.lo -MD -MP -MF .deps/malloc.Tpo -c -o malloc.lo malloc.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -MT malloc.lo -MD -MP -MF
.deps/malloc.Tpo -c malloc.c -fPIC -DPIC -o .libs/malloc.o
malloc.c: In function 'umem_malloc_init_hook':
malloc.c:447:2: warning: '__malloc_hook' is deprecated (declared at
/usr/include/malloc.h:176)
malloc.c:449:3: warning: '__malloc_hook' is deprecated (declared at
/usr/include/malloc.h:176)
malloc.c:450:3: warning: '__free_hook' is deprecated (declared at
/usr/include/malloc.h:173)
malloc.c:451:3: warning: '__realloc_hook' is deprecated (declared at
/usr/include/malloc.h:179)
malloc.c:452:3: warning: '__memalign_hook' is deprecated (declared at
/usr/include/malloc.h:183)
malloc.c: At top level:
malloc.c:456:8: error: conflicting type qualifiers for
'__malloc_initialize_hook'
/usr/include/malloc.h:170:38: note: previous declaration of
'__malloc_initialize_hook' was here
make[1]: *** [malloc.lo] Error 1
make[1]: Leaving directory
`/var/tmp/portage/sys-fs/zfs-fuse-9999/work/zfs-fuse-9999/src/src/lib/libumem'
make: *** [all] Error 2
scons: *** [lib/libumem/libumem.a] Error 2
scons: building terminated because of errors.


scons 2.1.0 here, btw.

Thanks for any feedback, Stefan
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
Emmanuel Anne
2012-04-24 10:00:15 UTC
Permalink
Here is a fix for the problem when compiling zfs-fuse with glibc 2.14.
It's committed in my repository (master branch).

---------- Forwarded message ----------
From: Stefan G. Weichinger <gmail-0cGGFY0Wf+KzZXS1Dc/***@public.gmane.org>
Date: 2012/4/23
Subject: Re: [zfs-fuse] Fwd: slow start of zfs pool, rebuilding zfs-fuse
from git
Post by Emmanuel Anne
2) Compilation failure is probably because of libc6-dev-2.14 or higher.
In debian testing we still have 2.13, so I'll stick with it for now ! ;-)
As mentioned in the other thread (and fearing that my replies won't get
to the list *again*) I managed to patch the sources to compile with
glibc-2.15-r1 (gentoo-syntax).

Small fix, my guide was:

http://groups.google.com/group/zfs-fuse/browse_thread/thread/63863046124c54c?pli=1

S
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
Loading...