[Bug 208719] PROBLEM: IO lockup on reiserfs RAID50 array.

[Bug 208719] PROBLEM: IO lockup on reiserfs RAID50 array.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

Jens Axboe (axboe@kernel.dk) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Block Layer                 |ReiserFS
           Assignee|axboe@kernel.dk             |reiserfs-devel@vger.kernel.
                   |                            |org
            Product|IO/Storage                  |File System

--- Comment #2 from Jens Axboe (axboe@kernel.dk) ---
Most likely a reiserfs issue, please re-assign the bug. I'd also strongly
reconsider using a filesystem that is actively maintained...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208719] PROBLEM: IO lockup on reiserfs RAID50 array.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

--- Comment #3 from deference@null.net ---
Thanks for your help!
I will forward this to the reiserfs maintainer.
I've managed to verify that all disks are accessible (smartctl -a /dev/sdX) and
that the RAID array is working and accessible (mdadm --detail and echo-ing
check/idle to the array and seeing progress).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208719] PROBLEM: IO lockup on reiserfs FS.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

deference@null.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|PROBLEM: IO lockup on       |PROBLEM: IO lockup on
                   |reiserfs RAID50 array.      |reiserfs FS.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208719] PROBLEM: IO lockup on reiserfs FS.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

--- Comment #4 from deference@null.net ---
On the suggestion to not use reiserfs:

My interest in using reiserfs was so that I would have tail packing. I've
searched online and can't find another FS with this function for Linux.
The reason I need tail packing is because I keep a bunch of mostly git
repositories on my system. These contain a lot of files that are either small
or are empty. I could try to hardlink all the empty files and small duplicate
files, but git would complain. I could compress the source code like I do with
normal code bases, but then I'd need to decompress and update them all.
Writing a script to do that would be nothing, it's just the time involved
compressing/decompressing that would be a waist (which is saying nothing
compared to git's love for full histories instead of up-to-the-last-4-versions
or something).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208719] PROBLEM: IO lockup on reiserfs FS.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

--- Comment #5 from deference@null.net ---
I should add that in chasing down this bug I have tried all the IO schedulers
available (noop deadline and cfq).
Cfq is the one I'm now using to reproduce this.

Also, I don't know if it makes a difference, but when the system first starts
up it takes 20m to get from the login manager to having my web browsers restart
and get all their pages from online. It might be because there is a lot of IO
going on or it might be that there are several stalls in the scheduling; just
not bad enough to cause a hung task problem like above.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208719] PROBLEM: IO lockup on reiserfs FS.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=208719

deference@null.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #6 from deference@null.net ---
This bug appears to have been fixed some where between 4.14.X and the 5.17.X
series.
I don't know why the fix wasn't backported, but it doesn't really matter to me
as I can run the newer kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.