10/10/2014 firstname.lastname@example.org :
I'm running 3.16.4-1.g7a8842b-desktop x86_64 from kernel:stable and I observe this on a system without any reiserfs partitions:
# ps axu | grep [r]eiser root 16287 0.0 0.0 0 0 ? S< Oct09 0:00 [reiserfs/sda4] root 16431 0.0 0.0 0 0 ? S< Oct09 0:00 [reiserfs/sda9] root 25392 0.0 0.0 0 0 ? S< Oct08 0:00 [reiserfs/sda4] root 25561 0.0 0.0 0 0 ? S< Oct08 0:00 [reiserfs/sda9]
# lsmod | grep reiser #
On 8 and 9/10, the system log indicates that os-prober attempted to mount sda4 and sda9 using every possible filesystem kernel module, but sda4 is an extended partition and sda9 is an unformatted one, which probably resulted in reiserfs kernel threads remaining even after I unloaded the reiserfs kernel module. To verify this, every time I run:
#mount /dev/sda4 /mnt -t reiserfs mount: wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
#modprobe -r reiserfs
another reiserfs kernel thread is added to the aforementioned ones.
I confirm this on tumbleweed x86_64. The kernel is 3.16.3-49.gd2bbe7f-desktop. Here is what I did as a test:
dd </dev/zero >plop bs=1M count=1 for i in $(seq 100); do mount -t reiserfs plop /mnt/ -o loop; done
And now I have a hundred reiserfs kernel threads, even after unloading the module.
Should I file a bug report about this?