| View previous topic :: View next topic |
| Author |
Message |
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
 Posted: Thu Jan 08, 2015 11:12 pm Post subject: Why would reiser be messing with ext3? |
 |
|
A few days ago, while checking resource usage with top, I noticed this:
Now this is strange, because a) sda3 is my / partition and b) it has always been formatted as ext3. I used to have a couple of hot-pluggable disks formatted with reiserfs, so I had enabled reiserfs support in the kernel, but I rarely use them any more. My /boot (sda1) is also ext3 and all of the other partitions are ext4.
I checked configuration files and logs, but there is no mention of reiserfs having something to do with sda3.
In fstab I have:
| Code: | | /dev/sda3 / ext3 defaults,noatime 0 1 |
/proc/mounts lists this:
| Code: | | /dev/sda3 / ext3 rw,noatime,errors=continue,barrier=1,data=ordered 0 0 |
during boot, everything seems in order:
| Code: | Jan 8 21:42:39 localhost kernel: sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
Jan 8 21:42:39 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Jan 8 21:42:39 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Jan 8 21:42:39 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 8 21:42:39 localhost kernel: sda: sda1 sda2 sda3 sda4 < sda5 >
Jan 8 21:42:39 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jan 8 21:42:39 localhost kernel: EXT3-fs (sda3): mounted filesystem with ordered data mode
Jan 8 21:42:39 localhost kernel: EXT3-fs (sda3): using internal journal
Jan 8 21:42:39 localhost kernel: Adding 1048572k swap on /dev/sda2. Priority:-1 extents:1 across:1048572k FS
Jan 8 21:42:39 localhost kernel: EXT3-fs (sda1): using internal journal
Jan 8 21:42:39 localhost kernel: EXT3-fs (sda1): mounted filesystem with ordered data mode
Jan 8 21:42:39 localhost kernel: EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
|
and from tune2fs I get this (notice the magic number, definitely not reiserfs):
| Code: | # tune2fs -l /dev/sda3
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /run/media/user/d095b999-3ebd-4a62-b0e8-730575eb28fd
Filesystem UUID: d095b999-3ebd-4a62-b0e8-730575eb28fd
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: journal_data_ordered
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 565248
Block count: 2236416
Reserved block count: 111820
Free blocks: 481783
Free inodes: 159636
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 383
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Fri Oct 31 00:12:38 2008
Last mount time: Thu Jan 8 21:42:23 2015
Last write time: Thu Jan 8 21:42:20 2015
Mount count: 5
Maximum mount count: 31
Last checked: Fri Jan 2 04:15:48 2015
Check interval: 15552000 (6 months)
Next check after: Wed Jul 1 05:15:48 2015
Lifetime writes: 48 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Journal inode: 8
First orphan inode: 308555
Default directory hash: tea
Directory Hash Seed: 6b444b17-fbee-4a26-b739-df1ef94c232a
Journal backup: inode blocks |
Another funny thing I noticed while looking into this was that only sda3 and sda1 do not have the correct entry in statfs as to where they were last mounted. Instead of / and /boot respectively, they show a mount point from when I had shrunk/grown them with a live CD a few years ago. But this is not important (at least I think it isn't).
It's not that I have a problem with this system, but why is that reiserfs/sda3 process always there? Given that ext4's subsystem is capable of handling ext3 partitions, should I compile reiserfs as a module for when it is needed and disable ext3 in the kernel? Would that possibly help in any way? |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9882
Location: almost Mile High in the USA
|
| Posted: Fri Jan 09, 2015 12:11 am Post subject: |
|
|
post the exact 'top' output
My guess is that you had a corrupt screen capture... *shrug*
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Fri Jan 09, 2015 1:31 pm Post subject: |
|
|
| eccerr0r wrote: | post the exact 'top' output
My guess is that you had a corrupt screen capture... *shrug* |
No, it's always there.
From top:
| Code: | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
[...]
595 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 reiserfs/sda3
[...]
|
and
| Code: | # ps ax | grep reiser
595 ? S< 0:00 [reiserfs/sda3]
|
I've run grep inside my /etc/ folder and it didn't find anything about sda3 and reiserfs. |
|
| Back to top |
|
|
s4e8
Guru
Joined: 29 Jul 2006
Posts: 311
|
| Posted: Fri Jan 09, 2015 1:46 pm Post subject: |
|
|
add
rootfstype=ext3 root=/dev/sda3
to grub boot line, and disable initrd. |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Fri Jan 09, 2015 3:39 pm Post subject: |
|
|
| Quote: | add
rootfstype=ext3 root=/dev/sda3
to grub boot line, and disable initrd. |
I never had an initrd on this machine and having to specify the rootfstype, even though ext3 was in the kernel, didn't seem the right way to go about this (no offence  ). I followed my own advice and set CONFIG_REISERFS_FS to be a module, unset CONFIG_EXT3_FS and CONFIG_EXT2_FS and enabled CONFIG_EXT4_USE_FOR_EXT23.
Now I have:
| Code: | # ps ax | grep sda3
597 ? S 0:00 [jbd2/sda3-8]
|
The reiserfs module springs into action when I plug in the disk with the Reiser filesystem, but other than that, it doesn't load.
So the problem (if you can call it that) has been circumvented, but why oh why would it occur in the first place? |
|
| Back to top |
|
|
limn
l33t
Joined: 13 May 2005
Posts: 997
|
| Posted: Fri Jan 09, 2015 3:42 pm Post subject: |
|
|
If you look at the parent PID of 595 it is 2. When you booted the kernel spun up the thread.
| Code: | | root 2 0 0 2014 ? 00:00:00 [kthreadd] |
Perhaps the reiserfs code in the kernel stored the partition information somehow.
On one of my systems.
| Code: | $ grep CONFIG_JFS_FS .config
CONFIG_JFS_FS=y
|
| Code: |
$ ps -ef | grep jfs
root 49 2 0 2014 ? 00:00:00 [jfsIO]
root 57 2 0 2014 ? 00:00:00 [jfsCommit]
root 59 2 0 2014 ? 00:00:00 [jfsSync]
|
There are no JFS partitions attached, and the box has been booted since there were.
As the output shows, these threads consume no resources, other than the overhead of an entry in the process table and some fraction of a millisecond delay at boot. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9882
Location: almost Mile High in the USA
|
| Posted: Fri Jan 09, 2015 4:01 pm Post subject: |
|
|
Probably a kernel bug then, maybe pointer chasing problem printing the wrong module, but I highly doubt it was actually using reiserfs.
Weird.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Fri Jan 09, 2015 4:13 pm Post subject: |
|
|
| limn wrote: |
Perhaps the reiserfs code in the kernel stored the partition information somehow.
|
Is that possible? Any guesses as to where such information might be stored?
| Quote: | | As the output shows, these threads consume no resources, other than the overhead of an entry in the process table and some fraction of a millisecond delay at boot. |
But they don't "hijack" any of your other partitions.
| eccerr0r wrote: | Probably a kernel bug then, maybe pointer chasing problem printing the wrong module, but I highly doubt it was actually using reiserfs.
Weird. |
Besides jbd2 now managing sda1 and sda3, statfs information has been updated:
| Code: |
# tune2fs -l /dev/sda1 | grep "Last mounted"
Last mounted on: /boot
# tune2fs -l /dev/sda3 | grep "Last mounted"
Last mounted on: /
|
I have to agree. Weird. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9882
Location: almost Mile High in the USA
|
| Posted: Fri Jan 09, 2015 5:45 pm Post subject: |
|
|
What kernel version?
Must be fairly recent as I didn't see the EXT4 driver able to use EXT2/EXT3 partitions before...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Fri Jan 09, 2015 6:30 pm Post subject: |
|
|
| eccerr0r wrote: | What kernel version?
Must be fairly recent as I didn't see the EXT4 driver able to use EXT2/EXT3 partitions before... |
I suppose you are referring to EXT4_USE_FOR_EXT23. This has existed for quite a few years, at least since version 2.6.30something, but if you're using menuconfig, you won't see it unless you disable support for ext2/3. |
|
| Back to top |
|
|
limn
l33t
Joined: 13 May 2005
Posts: 997
|
| Posted: Fri Jan 09, 2015 7:06 pm Post subject: |
|
|
| al_chem wrote: | | Is that possible? Any guesses as to where such information might be stored? |
Perhaps the process just decided that it ought be on / and the information was not stored. I do not know.
There are things you can do to further investigate. It depends on how much time and effort you want to put into it. The evidence may be gone now.
I added reiserfs support to a test box that has never seen a Reiser filesystem and it did not spin up a reiserfs thread. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Jan 09, 2015 7:38 pm Post subject: |
|
|
I have one wild guess: reiser3 has some... interesting partition detection heuristics (there's warnings somewhere about reiserfsck potentially nuking entire filesystems if they contain a loopback image that contains a reiserfs). So maybe it's trying to mount sda3, realising far too late that it's actually ext3, then trying to fix the screwup by jumping to ext3 code but forgetting to fix the kthread name.
My advice is don't enable a FS driver unless you intend to use it soon, and only use =Y for the ones you need during boot.
| eccerr0r wrote: | What kernel version?
Must be fairly recent as I didn't see the EXT4 driver able to use EXT2/EXT3 partitions before... |
Ext4 has always been able to mount ext2/3 partitions. That option just makes the kernel try to use it by default, and shuts up any warnings it might print. The only difference between all 3 are the feature flags they use. |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Fri Jan 09, 2015 7:53 pm Post subject: |
|
|
| Ant P. wrote: | | I have one wild guess: reiser3 has some... interesting partition detection heuristics (there's warnings somewhere about reiserfsck potentially nuking entire filesystems if they contain a loopback image that contains a reiserfs). |
The only correlation I could come up with was the "tea" directory hash algorithm. ReiserFS supports r5, rupasov and tea while the ext family supports legacy, half_MD4 and tea. No idea if that would be enough to justify what happened, though. |
|
| Back to top |
|
|
s4e8
Guru
Joined: 29 Jul 2006
Posts: 311
|
| Posted: Sat Jan 10, 2015 2:39 am Post subject: |
|
|
| reiserfs workqueue/kthread only started when partitions mounted as reiserfs. Your partition maybe contain both valid ext3 and reiserfs superblock(yes, it's possible, because ext3 superblock offset at 1K and reiserfs at 64K). Without rootfstype, kernel may probe and try-mount root as reiserfs. |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Sat Jan 10, 2015 3:49 am Post subject: |
|
|
| s4e8 wrote: | | reiserfs workqueue/kthread only started when partitions mounted as reiserfs. Your partition maybe contain both valid ext3 and reiserfs superblock(yes, it's possible, because ext3 superblock offset at 1K and reiserfs at 64K). Without rootfstype, kernel may probe and try-mount root as reiserfs. |
This made sense, so I copied the first 36KB from the disk to a file and opened it in a hex editor. I did find the ext3's 0x53 0xEF sequence, though not where I thought it would be, but I could not find "ReIsEr2Fs". Perhaps I did something wrong, I'm never too sure about dd. Does this look right to you?
| Code: | | dd if=/dev/sda3 of=part_start bs=4096 count=9 |
|
|
| Back to top |
|
|
s4e8
Guru
Joined: 29 Jul 2006
Posts: 311
|
| Posted: Sat Jan 10, 2015 6:03 am Post subject: |
|
|
| al_chem wrote: | | s4e8 wrote: | | reiserfs workqueue/kthread only started when partitions mounted as reiserfs. Your partition maybe contain both valid ext3 and reiserfs superblock(yes, it's possible, because ext3 superblock offset at 1K and reiserfs at 64K). Without rootfstype, kernel may probe and try-mount root as reiserfs. |
This made sense, so I copied the first 36KB from the disk to a file and opened it in a hex editor. I did find the ext3's 0x53 0xEF sequence, though not where I thought it would be, but I could not find "ReIsEr2Fs". Perhaps I did something wrong, I'm never too sure about dd. Does this look right to you?
| Code: | | dd if=/dev/sda3 of=part_start bs=4096 count=9 |
|
you can hexedit a partition:
hexedit /dev/sda3
goto offset 0x10000, clear the reiserfs magics. |
|
| Back to top |
|
|
limn
l33t
Joined: 13 May 2005
Posts: 997
|
| Posted: Sat Jan 10, 2015 11:51 am Post subject: |
|
|
| al_chem wrote: | | it has always been formatted as ext3 |
You are thinking reiserfs is mucking with other filesystem's superblocks without being told to? |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Sat Jan 10, 2015 12:16 pm Post subject: |
|
|
| s4e8 wrote: |
you can hexedit a partition:
hexedit /dev/sda3
goto offset 0x10000, clear the reiserfs magics. |
 I would have never thought of that... Anyway, I went over the first couple of megabytes just to be sure, I saw 53 EF at 438, but I didn't find anything belonging to reiserfs. |
|
| Back to top |
|
|
al_chem
n00b
Joined: 21 Apr 2014
Posts: 10
|
| Posted: Sat Jan 10, 2015 1:04 pm Post subject: |
|
|
| limn wrote: | | You are thinking reiserfs is mucking with other filesystem's superblocks without being told to? |
I honestly don't know what to make of it and I have no idea for how long this had been going on unnoticed.
*We have a kernel with native support for ext2,3,4 and reiserfs.
*The root partition is formatted to ext3 and as we've just established, there are no "foreign" superblocks.
*At boot, it is recognized correctly as ext3 and it is picked up by the ext3 system and properly mounted. Whenever the time comes for a filesystem check, it is done by fsck.ext3.
*Then for some reason, a reiserfs thread appears that attaches (don't know if this is the right term) itself to that same partition.
As for the missing statfs info (the "Last mounted on" part), I'm inclined to believe that it has to do with a limitation of ext3 rather than anything else, as the /boot partition, which is also formatted to ext3 didn't update that info either and it was never harassed by reiserfs.
Now that reiserfs is compiled as a module and ext4 handles both ext3 and ext4 partitions, everything seems in order.
I will keep the old kernel for a while, in case anyone comes up with an idea as to what was happening.
Thank you all for your input so far! |
|
| Back to top |
|
|
|
Kernel & Hardware
