Issue tracker — Rudd-O.com

Tracker log

An overview of recent activity in the tracker.

Seth Heeren added a new response to »S38zfs-fuse (1142): /proc/1163/oom_adj is deprecated, please use /proc/1163/oom_score_adj instead.«:

Thanks Tim!

things are not always very complicated but the help is very much appreciated. I had never come round to it; The upstart script has been using `oom never` forever:

https://github.com/[…]/zfs.upstart

I have tested this and updated the relevant initscripts under contrib/ and will notify the list on the linked thread.

See your credits:

http://gitweb.zfs-fuse.net/[…]3a1e66f49990ce3523bc9f0a31e

Issue state: unconfirmed → resolved. Target release: None → 0.7.0. Responsible manager: (UNASSIGNED) → sgheeren. Added 4 day(s) ago.

Tim Radke added a new response to »S38zfs-fuse (1142): /proc/1163/oom_adj is deprecated, please use /proc/1163/oom_score_adj instead.«:

if [ -f "/proc/$PID/oom_score_adj" ]
then
echo -1000 > "/proc/$PID/oom_score_adj"
else
echo -17 > "/proc/$PID/oom_adj"
fi

Added 4 day(s) ago.

Tim Radke added a new response to »S38zfs-fuse (1142): /proc/1163/oom_adj is deprecated, please use /proc/1163/oom_score_adj instead.«:

According to https://bugzilla.mindrot.org/show_bug.cgi?id=1838 oom_score_adj should be set to -1000 to get the same behavior as oom_adj set to -17.

Added 4 day(s) ago.

Seth Heeren added a new response to »Tarball is empty«:

Hah. It's fixed now - apparently the upload error was transitive.

wget http://zfs-fuse.net/releases/0.7.0/zfs-fuse-0.7.0.tar.bz2

should now result in a tarball with md5sum of 4b060af9f3604f1b2c5e8984b8a623e4

Issue state: open → resolved. Responsible manager: RuddO → sgheeren. Added 27 day(s) ago.

Seth Heeren added a new response to »Tarball is empty«:

Thanks for the report. This must have been broken by the recent site's migration.

I'm unable to upload a fixed tarball, probably due to the same technical difficulty.
Forwarded to the sys-admin.

May I recommend the maint snapshot for now:

http://gitweb.zfs-fuse.net/[…]l;a=snapshot;h=maint;sf=tgz

Or, use gitweb to retrieve a raw tarball of the official 0.7.0 release:

http://gitweb.zfs-fuse.net/[…]l;a=snapshot;h=0.7.0;sf=tgz

To get the exact tar ball you would have gotten from the broken link, run ./contrib/make-dist
to create zfs-fuse-0.7.0.tar.bz2 inside the projects root directory.

Issue state: unconfirmed → open. Severity: Medium → Important. Target release: None → 0.7.0. Responsible manager: (UNASSIGNED) → RuddO. Added 27 day(s) ago.

New issue »Tarball is empty« added by (anonymous)

I want to obtain a copy of ZFS-Fuse 0.7.0, but the tarball is empty.

Added 27 day(s) ago.

(anonymous) added a new response to »Spec changes required to build rpm«:

No bullshit and well drafted, tyvm for this content, http://ejaculationtrainerhelp4you.info ejaculation, xqntih,

Added 53 day(s) ago.

(anonymous) added a new response to »Spec changes required to build rpm«:

No but they can damage your liver. Stop taking those vitamins. Some of those are fat soluble which means they are stored up in your fat and released over time. These types of vitamins are toxic in large amounts because the body doesn't get rid of them like they do water soluble vitamins, like vitamin c, which you pee out., http://acneskincareonline.info acne skin care, 8-]],

Added 53 day(s) ago.

New issue »max-arc-size not honored, arc reclaim working, but way to slow« added by Gregor Kopka

I setup some servers with
Linux version 3.0.6-gentoo (root@server) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) )
and zfs-fuse 0.7.0 as 2 device mirrors on cryptsetup secured drives.

/etc/zfs/zfsrc is:
| vdev-cache-size = 10
| max-arc-size = 10240
| zfs-prefetch-disable
| fuse-attr-timeout = 3600
| fuse-entry-timeout = 3600
| fuse-mount-options = default_permissions

The machine has 16GB of RAM and is mainly used to serve to windows client through samba 3.5.11.
Other relevant things this machines do is:
- serving small-volume databases (firebird, postgresql), ~1GB total
- squid web proxy
- snapshotting the pool hourly
- replication via zfs send/recv (streamdumps stored in files and replicated through rsync since the uplinks are unstable).

After 2-3 weeks of operation i start to see zfs-fuse being pushed into swap since it claimed way more than the 10GB configured as ARC.
Also unkillable defunct smbd processes start to show up, my guess is they wait for I/O from zfs which is somehow never completed.
No OOM-Killer messages sighted (i guess since swap is there).

At this point the only solution is to cold-reboot the machine, ending zfs-fuse isn't possible anymore (since the defunct smbd processes hold locks into zfs filesystems), even after shutting down swap (which took hours).

Any suggestions how to deal with this, fix it, or provide additional information so smarter than me people can fix this?

Added 57 day(s) ago.

New issue »max-arc-size nor honored, arc reclaim working, but way to slow« added by Gregor Kopka

Added 57 day(s) ago.

(anonymous) added a new response to »Split Pool is Lost After Rebooting «:

This was an out of the box, latest Ubuntu install of zfs-fuse. No changes to the default configuration were made.

I did discover that the zfs.cache lives in /var/lib/zfs/zfs.cache instead of what's defined in the documentation.

I'm guessing split needs to implement the export functionality, or a subfunction of the export functionality which updates the zfs.cache file. I'm guessing the function call is missing.

Hope this helps.

Added 87 day(s) ago.

Seth Heeren added a new response to »Split Pool is Lost After Rebooting «:

Could you show us your init script, /etc/default/zfs-fuse and /etc/zfs/zfsrc if applicable?

Also, what version/distribution is this. If you compiled it yourself, please specify the source revision and compilation flags (mainly, debug=n option used).

I'll try to reproduce it using the information.

Cheers,
Seth

-----

NOTE from the tracker front page regarding attaching information: If you want to attach a non-text attachment to a bug report, please go to the Wiki area, click Add new..., then File or Image as necessary, upload the file, and paste a link to the uploaded file in your bug report. We deeply apologize for this inconvenience while we fix it.

Added 89 day(s) ago.

Seth Heeren added a new response to »Split Pool is Lost After Rebooting «:

Responsible manager: (UNASSIGNED) → sgheeren. Added 89 day(s) ago.

New issue »Split Pool Disappears If -R Option isn't Used « added by (anonymous)

Additionally, splitting a pool should mount
the split pool as the pool name under slash
by default unless the -R option is used.

Created a mirrored pool.
Added an additional disk to each mirror.
Split the mirror without using -R.
zpool status
Added an additional disk to each mirror.
Split the mirror using -R.
zpool status
export mirror
import mirror
zpool status

Added 89 day(s) ago.

New issue »Split Pool is Lost After Rebooting « added by (anonymous)

Created a mirrored pool.
Added an additional disk to each mirror.
Split the mirror.
Reboot.
Split mirror is gone.

Added 89 day(s) ago.

New issue »__malloc_initialize_hook in glibc 2.14 changed « added by (anonymous)

Compiling git version 3b32fa7133e8... with gcc using glibc 2.14 stable release results in following error:

------------
make[1]: Entering directory `/data/local_pkg/zfs/zfs-fuse-git/src/official/src/lib/libumem'
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT malloc.lo -MD -MP -MF ".deps/malloc.Tpo" -c -o malloc.lo malloc.c; \
then mv -f ".deps/malloc.Tpo" ".deps/malloc.Plo"; else rm -f ".deps/malloc.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -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) [-Wdeprecated-declarations]
malloc.c:449:3: warning: '__malloc_hook' is deprecated (declared at /usr/include/malloc.h:176) [-Wdeprecated-declarations]
malloc.c:450:3: warning: '__free_hook' is deprecated (declared at /usr/include/malloc.h:173) [-Wdeprecated-declarations]
malloc.c:451:3: warning: '__realloc_hook' is deprecated (declared at /usr/include/malloc.h:179) [-Wdeprecated-declarations]
malloc.c:452:3: warning: '__memalign_hook' is deprecated (declared at /usr/include/malloc.h:183) [-Wdeprecated-declarations]
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
------------

A temporary fix (until glibc 2.15 will be released) is to add __volatile type qualifiers for '__malloc_initialize_hook':

------------
diff --git a/src/lib/libumem/malloc.c b/src/lib/libumem/malloc.c
index 7eec207..5a4d763 100644
--- a/src/lib/libumem/malloc.c
+++ b/src/lib/libumem/malloc.c
@@ -453,7 +453,7 @@ static void __attribute__((constructor)) umem_malloc_init_hook(void)
        }
}

-void (*__malloc_initialize_hook)(void) = umem_malloc_init_hook;
+void (* __volatile __malloc_initialize_hook)(void) = umem_malloc_init_hook;

#else
void __attribute__((constructor))
-----------

System in use:
-----------
NPTL 2.14

GNU C Library stable release version 2.14, by Roland McGrath et al.
Copyright (C) 2011 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.6.1 20110819 (prerelease).
Compiled on a Linux 3.0.1 system on 2011-09-08.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC

gcc (GCC) 4.6.1 20110819 (prerelease)

Linux angara 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU L 640 @ 2.13GHz GenuineIntel GNU/Linux

Added 123 day(s) ago.

Andras Korn added a new response to »xattr support broken, mangles permission bits on cp -a«:

Discussion related to this bug is taking place at http://groups.google.com/[…]/fe909a5fa8bef4d2?pli=1

Added 145 day(s) ago.

Seth Heeren added a new response to »xattr support broken, mangles permission bits on cp -a«:

Thanks for reporting this. The steps to reproduce seem very helpful.

I'm not personally aware of the way in which xattrs border with file permissions.

I'm forwarding the issue to the list, since Emmanuel is probably not following the tracker, and I suspect he uses xattrs himself.

Issue state: unconfirmed → open. Added 145 day(s) ago.

New issue »xattr support broken, mangles permission bits on cp -a« added by Andras Korn

Hi,

I'm using the prepackaged Ubuntu package, version 0.7.0-1ubuntu1~2.gbp43db46.

I enabled xattr support because I want to store posix ACLs on zfs (I realise they're not effective yet; I just wanted to be able to set them).

I noticed that when I copied or moved files, they would become mode 0600.

This appears to be caused by broken/half-working posix ACL support. Excerpt from strace cp -a file1 file2:

stat("file2", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("file1", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("file2", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("file1", O_RDONLY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("file2", O_WRONLY|O_TRUNC) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
read(3, "", 32768) = 0
utimensat(4, NULL, {{1315852659, 0}, {1315852659, 0}}, 0) = 0
flistxattr(3, (nil), 0) = 0
flistxattr(3, 0x7fffca5c2b80, 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7fffca5c2a60, 132) = -1 ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0
close(4) = 0
close(3) = 0

The fsetxattr() call seems to set file2 mode 0600 irrespective of the actual mode bits inside.

Added 146 day(s) ago.

Seth Heeren added a new response to »scons just builds one target«:

ah... good point. reminded me adding the --no-cache flag for packaging (it happened in 7c676af8c2c0, June 2010)

I had forgotten about that. Next time I'll remember to mention it

Cheers,
Closing

Issue state: unconfirmed → resolved. Added 155 day(s) ago.

Sections

Personal tools

Views

Tracker log