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 <emmanuel.a
...@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-fuse@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/libum em'
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
