# Why would reiser be messing with ext3?

## al_chem

A few days ago, while checking resource usage with top, I noticed this:

```
reiserfs/sda3
```

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:

```
/dev/sda3       /                       ext3            defaults,noatime     0 1
```

/proc/mounts lists this:

```
/dev/sda3 / ext3 rw,noatime,errors=continue,barrier=1,data=ordered 0 0
```

during boot, everything seems in order:

```
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):

```
# 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?

----------

## eccerr0r

post the exact 'top' output

My guess is that you had a corrupt screen capture... *shrug*

----------

## al_chem

 *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:

```
  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

```
# 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.

----------

## s4e8

add 

rootfstype=ext3 root=/dev/sda3

 to grub boot line, and disable initrd.

----------

## al_chem

 *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    :Smile:  ). 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:

```
# 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?

----------

## limn

If you look at the parent PID of 595 it is 2. When you booted the kernel spun up the thread.

```
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.

```
$ grep CONFIG_JFS_FS .config

CONFIG_JFS_FS=y

```

```

$ 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.

----------

## eccerr0r

Probably a kernel bug then, maybe pointer chasing problem printing the wrong module, but I highly doubt it was actually using reiserfs.

Weird.

----------

## al_chem

 *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:

```

# 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.

----------

## eccerr0r

What kernel version?

Must be fairly recent as I didn't see the EXT4 driver able to use EXT2/EXT3 partitions before...

----------

## al_chem

 *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.

----------

## limn

 *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.

----------

## Ant P.

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.

----------

## al_chem

 *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.

----------

## s4e8

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.

----------

## al_chem

 *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?

```
dd if=/dev/sda3 of=part_start bs=4096 count=9
```

----------

## s4e8

 *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?
> 
> ```
> ...

 

you can hexedit a partition: 

hexedit /dev/sda3

goto offset 0x10000, clear the reiserfs magics.

----------

## limn

 *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?

----------

## al_chem

 *s4e8 wrote:*   

> 
> 
> you can hexedit a partition: 
> 
> hexedit /dev/sda3
> ...

 

 :Shocked:  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.

----------

## al_chem

 *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!

----------

