Fwd: slow start of zfs pool, rebuilding zfs-fuse from git

52 views
Skip to first unread message

Emmanuel Anne

unread,
Mar 29, 2012, 5:46:49 PM3/29/12
to zfs-...@googlegroups.com
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 <li...@xunil.at>
Date: 2012/3/29
Subject: Fwd: slow start of zfs pool, rebuilding zfs-fuse from git
To: Emmanuel Anne <emmanu...@gmail.com>



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 <gm...@oops.co.at>
Antwort an: gm...@oops.co.at
An: zfs-...@googlegroups.com


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

Emmanuel Anne

unread,
Apr 24, 2012, 6:00:15 AM4/24/12
to zfs-...@googlegroups.com
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 <gm...@oops.co.at>
Date: 2012/4/23
Subject: Re: [zfs-fuse] Fwd: slow start of zfs pool, rebuilding zfs-fuse from git
To: zfs-...@googlegroups.com
Cc: Emmanuel Anne <emmanu...@gmail.com>



Am 2012-03-29 23:46, schrieb 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
Reply all
Reply to author
Forward
0 new messages