Reiser4 -enabled Linux 5.10.26
Niltze [Hello], all- We have just released a preliminary reiser4 -enabled Debian 11, codenamed Bullseye, minimal USB/ISO AMD64 image with Debianized kernel 5.10.26-2. It has been tested lightly -- as Debian gives the finishing touches to their upcoming operating system distribution. If anyone wants to give it a spin, here are the download link(s): https://metztli.it/bullseye/netboot/metztli-reiser4.iso https://metztli.it/bullseye/netboot/metztli-reiser4.iso.SHA256SUM If using USB device /dev/sdb, dd if=metztli-reiser4.iso of=/dev/sdb bs=4M; sync https://metztli.it/bullseye *No warranties whatsoever* Best Professional Regards. -- -- Jose R R http://metztli.it --- -- Download Metztli Reiser4: Debian Buster w/ Linux 5.10.20 AMD64 --- -- feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- -- or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin wrote: > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to > > generate a kernel component for my Debian-Installer (d-i). > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of > > components for d-i I built the d-i image. > > > > Fact is, the installer throws an error in *both* bare metal and VirtualBox > > 6.1.16: > > ... > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main > > --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg > > buster /target http://deb.debian.org/debian/ > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > /target/test-exec: Invalid argument > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file > > /test-exec (pid: 10077 comm: debootstrap) > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' > > mounted with noexec or nodev > > Dec 22 20:20:12 base-installer: error: exiting on error > > base-installer/debootstrap-failed > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' > > failed with error code 1 > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' > > failed. > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package > > description for brltty-udeb > > > > [...] > > > > > Apparently, d-i [Debian-installer] complains about being unable to set the > > test file executable and causes the error when 1 is returned. > > Notwithstanding, I manually verified that I am able to touch a file and set > > it +x executable. > > > > Furthermore, tricking the function return value to 0 I am able to make d-i > > continue with the latest SFRN5 installation (see [*trick*] below); yet, > > subsequently halts again with > > an apparently related error --can not proceed any further. > > > > Digging deeper with dmesg, we can see that apparently it is the kernel > > which cannot 'read' properly. Please find a partial dmesg log with relevant > > output > > from an attempt on my physical development machine. > > ... > > [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See > > reiser4.wiki.kernel.org for a description of Reiser4. > > [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no > > debug enabled > > [ 509.326270] device-mapper: uevent: version 1.0.3 > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: > > dm-de...@redhat.com > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 > > [ 509.915300] sdb: sdb1 sdb2 sdb3 > > [ 511.973360] sdb: sdb1 sdb2 sdb3 > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 > > across:9765884k FS > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3. > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > [ 643.759980] reiser4: brick /dev/sda6 activated > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > subsystem > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > (null) > > [ 643.813488] ext2 filesystem being mounted at /target/boot supports > > timestamps until 2038 (0x7fff) > > [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 > > comm: debootstrap) [*trick*] > > [ 898.761385] reiser4: brick /dev/sda6 deactivated > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3. > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > [ 999.093480] reiser4: brick /dev/sda6 activated > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > subsystem > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > (null) > > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports > > timestamps until 2038 (0x7fff) > > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 > &g
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Fri, Dec 25, 2020 at 8:44 AM Metztli Information Technology wrote: > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin > wrote: > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > > Niltze [ÃâôÃâ¬Ã°Ã²à ÃâòÃÆùÃâõ : Hello], Ed- > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to > > > generate a kernel component for my Debian-Installer (d-i). > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set > > > of components for d-i I built the d-i image. > > > > > > Fact is, the installer throws an error in *both* bare metal and > > > VirtualBox 6.1.16: > > > ... > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main > > > --debian-installer --resolve-deps > > > --keyring=/usr/share/keyrings/archive.gpg buster /target > > > http://deb.debian.org/debian/ > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > > /target/test-exec: Invalid argument > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file > > > /test-exec (pid: 10077 comm: debootstrap) > > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' > > > mounted with noexec or nodev > > > Dec 22 20:20:12 base-installer: error: exiting on error > > > base-installer/debootstrap-failed > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' > > > failed with error code 1 > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' > > > failed. > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package > > > description for brltty-udeb > > > > > > > [...] > > > > > > > > Apparently, d-i [Debian-installer] complains about being unable to set > > > the test file executable and causes the error when 1 is returned. > > > Notwithstanding, I manually verified that I am able to touch a file and > > > set it +x executable. > > > > > > Furthermore, tricking the function return value to 0 I am able to make > > > d-i continue with the latest SFRN5 installation (see [*trick*] below); > > > yet, subsequently halts again with > > > an apparently related error --can not proceed any further. > > > > > > Digging deeper with dmesg, we can see that apparently it is the kernel > > > which cannot 'read' properly. Please find a partial dmesg log with > > > relevant output > > > from an attempt on my physical development machine. > > > ... > > > [  508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See > > > reiser4.wiki.kernel.org for a description of Reiser4. > > > [  508.661951] SGI XFS with ACLs, security attributes, realtime, quota, > > > no debug enabled > > > [  509.326270] device-mapper: uevent: version 1.0.3 > > > [  509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) > > > initialised: dm-de...@redhat.com > > > [  509.902828]  sda: sda1 sda2 sda3 sda4 sda5 sda6 > > > [  509.915300]  sdb: sdb1 sdb2 sdb3 > > > [  511.973360]  sdb: sdb1 sdb2 sdb3 > > > [  627.525371] Adding 9765884k swap on /dev/sda3.  Priority:-2 > > > extents:1 across:9765884k FS > > > [  636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > > [  636.240812] NOTICE: brick /dev/sda6 has been registered > > > [  636.243003] reiser4 (sda6): found disk format 5.1.3. > > > [  643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > > [  643.759980] reiser4: brick /dev/sda6 activated > > > [  643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > > subsystem > > > [  643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > > (null) > > > [  643.813488] ext2 filesystem being mounted at /target/boot supports > > > timestamps until 2038 (0x7fff) > > > [  648.168730] kernel read not supported for file /test-exec (pid: 9876 > > > comm: debootstrap) [*trick*] > > > [  898.761385] reiser4: brick /dev/sda6 deactivated > > > [  991.001332] reiser4 (sda6): found disk f
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin wrote: > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > Niltze [ÃâôÃâ¬Ã°Ã²à ÃâòÃÆùÃâõ : Hello], Ed- > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to > > generate a kernel component for my Debian-Installer (d-i). > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of > > components for d-i I built the d-i image. > > > > Fact is, the installer throws an error in *both* bare metal and VirtualBox > > 6.1.16: > > ... > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main > > --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg > > buster /target http://deb.debian.org/debian/ > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > /target/test-exec: Invalid argument > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file > > /test-exec (pid: 10077 comm: debootstrap) > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' > > mounted with noexec or nodev > > Dec 22 20:20:12 base-installer: error: exiting on error > > base-installer/debootstrap-failed > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' > > failed with error code 1 > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' > > failed. > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package > > description for brltty-udeb > > > > [...] > > > > > Apparently, d-i [Debian-installer] complains about being unable to set the > > test file executable and causes the error when 1 is returned. > > Notwithstanding, I manually verified that I am able to touch a file and set > > it +x executable. > > > > Furthermore, tricking the function return value to 0 I am able to make d-i > > continue with the latest SFRN5 installation (see [*trick*] below); yet, > > subsequently halts again with > > an apparently related error --can not proceed any further. > > > > Digging deeper with dmesg, we can see that apparently it is the kernel > > which cannot 'read' properly. Please find a partial dmesg log with relevant > > output > > from an attempt on my physical development machine. > > ... > > [  508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See > > reiser4.wiki.kernel.org for a description of Reiser4. > > [  508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no > > debug enabled > > [  509.326270] device-mapper: uevent: version 1.0.3 > > [  509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) > > initialised: dm-de...@redhat.com > > [  509.902828]  sda: sda1 sda2 sda3 sda4 sda5 sda6 > > [  509.915300]  sdb: sdb1 sdb2 sdb3 > > [  511.973360]  sdb: sdb1 sdb2 sdb3 > > [  627.525371] Adding 9765884k swap on /dev/sda3.  Priority:-2 extents:1 > > across:9765884k FS > > [  636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > [  636.240812] NOTICE: brick /dev/sda6 has been registered > > [  636.243003] reiser4 (sda6): found disk format 5.1.3. > > [  643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > [  643.759980] reiser4: brick /dev/sda6 activated > > [  643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > subsystem > > [  643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > (null) > > [  643.813488] ext2 filesystem being mounted at /target/boot supports > > timestamps until 2038 (0x7fff) > > [  648.168730] kernel read not supported for file /test-exec (pid: 9876 > > comm: debootstrap) [*trick*] > > [  898.761385] reiser4: brick /dev/sda6 deactivated > > [  991.001332] reiser4 (sda6): found disk format 5.1.3. > > [  999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > [  999.093480] reiser4: brick /dev/sda6 activated > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > subsystem > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > (null) > > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports > > timestamps until 2038 (0x7fff) > > [ 6373.748413] kernel read not
Re: PROBLEM: Reiser4 hard lockup
On Sun, Oct 25, 2020 at 6:10 PM David Niklas wrote: > > I'll reply to both of you in this email. > > On Sun, 25 Oct 2020 02:04:22 -0700 (PDT) > Metztli Information Technology wrote: > > Niltze, David- > > > > A few observations are in order below: > > > > On Sat, Oct 24, 2020 at 1:39 PM David Niklas > > wrote: > > > > > > Hello, > > > > > > reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file > > system utilities should not be used to check/fix media formatted 'a > > priori' in SFRN 4.0.2 and vice-versa. > > Honestly, this is the first time I've heard about a Linux FS having > versioning other than a major one (NTFS IIRC is infamous for it's > incompatibilities). > > > > > Conclusion: I suggest you read up on the published reiser4 > > documentation and build *both* your kernel and reiser4progs utilities > > conforming to the more recent stable SFRN 4.0.2. > > I religiously read the reiser4 documentation prior to changing my FS. No > where do I recall seeing, on the wiki, or in the man pages, that there > was a need to use a newer reiser4 progs. > Ok, here it is: > https://reiser4.wiki.kernel.org/index.php/Reiser4_development_model > I'm not normally going to read a page that looks like it's for developers > as an end user which is why I didn't initially read it. > > > Prior to build reiser4progs 1.2.1 SFRN 4.0.2: > > libaal-1.0.7.tar.gz > > < https://sourceforge.net/projects/reiser4/files/reiser4-utils/ > > > > > then build reiser4progs-1.2.1.tar.gz SFRN 4.0.2 > > < > > https://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs/ > > > > > > > as any reiser4 patches for kernel 4.14 and higher conform to SFRN 4.0.2: > > https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-5.x/ > > > > citing, for the third time, reference email documenting the change, > > i.e. '2017-11-26 23:01:53 reiser4 SFRN 4.0.2 is not your father's > > reiser4 SFRN 4.0.1' < > > https://marc.info/?l=reiserfs-devel=151173731709826=2 > > > > > If you are going to use reiser4 kernel patches for linux 4.15.xy - > > 5.4.5 range, please make sure to *also* apply: [PATCH] reiser4: prevent > > system lockups: < > > https://marc.info/?l=reiserfs-devel=158086248927420=2 > > > > I was using 5.7.13 at the time. Should the crashes still be happening > because this patch is missing? Only "If you are going to use reiser4 kernel patches for linux 4.15.xy - 5.4.5 range," > It seems odd you'd mention it knowing > which kernel version I was using. I have to be proactive and anticipate a potential decision to use a lower version ;-) i.e., I am really baffled at how you were using reiser4 SFRN 4.0.2 patch for linux 5.7.13 -- yet built and were using old reiser4progs 1.1.x SFRN 4.0.1 :) It is not as if there were not reiser4 resources out there. One of the reasons I make available a reiser4 hack of Debian netboot ISOs on SourceForge is to provide some sort of reference implementation. If you do not like/trust the Debian metaframework OS hack installed onto your computer, fair, as you can only use the bootable iso to execute the commands suggested elsewhere by Ed to find out the proper SFRN and/or versions of the kernel and reiser4progs utilities which your *own* build might strive to match. > > > On Sun, 25 Oct 2020 13:50:15 +0100 > Edward Shishkin wrote: > > On 10/24/2020 10:36 PM, David Niklas wrote: > > > Hello, > > > Â > > > > Hi David, > > > > Thanks for the comprehensive report, which is definitely useful! > > Below you can find some hints and comments. > > > > (: > > > > > > It's a pity.. > > To be honest, I received complaints that reiser4 doesn't make > > a friendship with torrents long time ago. Unfortunately, I am in Europe, > > where it is impossible to use torrents that simply, without conflicts > > with local legislation. Respectively, I am not able to reproduce it, > > and the problem is still unfixed.. > > > I might try to reproduce this later and log the actual write patterns so > you can reproduce these crashes. Obviously, I'll have to learn how to > first. > > > > reiser4 mount option "dont_load_bitmap" is your friend. > > I knew about that, but I'm uncertain if it would change how reiser4 works > and then it will not cause the crash. > > > > I had also to manually chew through all the kernel .o files to find > > > where the kernel broke at (also attached). > > > > > > The command I used to create the reiser4 FS was: &g
Re: PROBLEM: Reiser4 hard lockup
Niltze, David- A few observations are in order below: On Sat, Oct 24, 2020 at 1:39 PM David Niklas wrote: > > Hello, > > # Intro > Pardon my tardiness in reporting this, I was stalling my disk upgrade to > help test a fix for a reiserfs problem. I needed to get my life going > again before taking the time to report this. > This is a heads up for a serious problem. I no longer use reiser4 > anymore because I can't have my kernel hard and soft locking up within > hours of booting and I don't use the 5.7.13. Therefore, I can't test a > fix for this, but I am willing to test future releases of reiser4 on a > test partition. > The problem might lie elsewhere in the Linux kernel considering how many > panics it threw before hard locking up, but I am starting with the > reiser4 maintainer and ML because kernel 5.8.X without loading the > reiser4 module has been quite stable. > > # 2. Description > The Linux kernel hard and/or soft locks up only hours after booting when > using reiser4. It throws several panics before hand. The applications that > trigger this bug are rtorrent + dar + sync. > > # 3. Keywords > hard lockup, soft lockup, reiser4, rcu > > # 4. Kernel information. > 5.7.13 x86_64 > > # 5. Kernel without bug. > NA > > # 6. Oops message. > Way too big. See attached. > Here's something to wet your tongue: > > [ 4483.173140] NMI backtrace for cpu 0 > [ 4483.173143] CPU: 0 PID: 21593 Comm: dar Not tainted > 5.7.13-nopreempt-Radeon-SI-dav10 #4 [ 4483.173144] Hardware name: > Gigabyte Technology Co., Ltd. To be filled by O.E.M./970A-DS3P, BIOS FD > 02/26/2016 [ 4483.173145] Call Trace: [ 4483.173148]  > [ 4483.173153]  dump_stack+0x66/0x8b > [ 4483.173155]  nmi_cpu_backtrace+0x89/0x90 > [ 4483.173157]  ? lapic_can_unplug_cpu+0x90/0x90 > ... > [ 4483.173213]  jput_final+0x303/0x320 [reiser4] > [ 4483.173220]  reiser4_invalidate_list+0x3e/0x50 [reiser4] > [ 4483.173228]  reiser4_write_logs+0x76/0x560 [reiser4] > ... > [ 4557.097894] NMI watchdog: Watchdog detected hard LOCKUP on cpu 2 > ... > [ 4557.600871]  __schedule+0x288/0x5d0 > [ 4557.600874]  schedule+0x4a/0xb0 > [ 4557.600875]  schedule_timeout+0x14a/0x300 > ... > > # 7. Shell script to trigger the problem. > I tried to create an artificial workload using dd, cp, sync, and other > programs to cause the fault without success. > > # 8. Enviroment. > % dar --version > >  dar version 2.5.17, Copyright (C) 2002-2052 Denis Corbin >   Long options support    : YES > >  Using libdar 5.13.0 built with compilation time options: >   Libz compression (gzip)    : YES >   Libbz2 compression (bzip2)  : YES >   Liblzo2 compression (lzo)   : YES >   Liblzma compression (xz)   : YES >   Strong encryption (libgcrypt): YES >   Public key ciphers (gpgme)  : NO >   Extended Attributes support  : YES >   Large files support (> 2GB)  : YES >   ext2fs NODUMP flag support  : YES >   Special allocation scheme   : NO >   Integer size used       : unlimited >   Thread safe support      : YES >   Furtive read mode support   : YES >   Linux ext2/3/4 FSA support  : YES >   Mac OS X HFS+ FSA support   : NO >   Detected system/CPU endian  : little >   Posix fadvise support     : YES >   Large dir. speed optimi.   : YES >   Timestamp read accuracy    : 1 microsecond >   Timestamp write accuracy   : 1 microsecond >   Restores dates of symlinks  : YES > >  compiled the Nov 23 2018 with GNUC version 6.3.0 20170516 >  dar is part of the Disk ARchive suite (Release 2.5.17) > > %  rtorrent -h > Rakshasa's BitTorrent client version 0.9.6. > > %  sync --version > sync (GNU coreutils) 8.26 > > % mkfs.reiser4 --version > mkfs.reiser4 1.1.0 > Format release: 4.0.1 > > % fsck.reiser4 --version > fsck.reiser4 1.1.0 > Format release: 4.0.1 reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file system utilities should not be used to check/fix media formatted 'a priori' in SFRN 4.0.2 and vice-versa. > > % head -n28 /proc/cpuinfo # The info in just repeated for all the%  cores. > processor    : 0 > vendor_id    : AuthenticAMD > cpu family    : 16 > model      : 10 > model name    : AMD Phenom(tm) II X6 1090T Processor > stepping     : 0 > microcode    : 0x1bf > cpu MHz     : 2011.953 > cache size    : 512 KB > physical id   : 0 > siblings     : 5 > core id     : 0 > cpu cores    : 5 > apicid      : 0 > initial apicid  : 0 > fpu       : yes > fpu_exception  : yes > cpuid level   : 6 > wp        : yes > flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext > fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl > nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm >
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On Sat, Aug 29, 2020 at 2:54 AM Edward Shishkin wrote: > > On 08/28/2020 01:50 AM, Edward Shishkin wrote: > > > > > > On 08/27/2020 11:53 PM, Metztli Information Technology wrote: > >> On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin > >> wrote: > >>> > >>> [...] > >>> > >>>> > >>>> FYI Although not officially, the Debian metaframework Buster AMD64 > >>>> distribution might be the first to support native installation of > >>>> Reiser4 SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system > >>>> utilities. > >>>> > >>>> I have already made a couple of successful Metztli Reiser4 SFRN 5 > >>>> native installations onto ~100 GB slices, which root file system is > >>>> formatted in 'Reiser5' and 1 GB /boot in JFS. > >>>> https://metztli.it/reiser5 (Screenshot 600x338 size) > >>>> > >>>> The upgraded netboot installation media metztli-reiser4-sfrn5.iso is > >>>> available at: > >>>> https://sourceforge.net/projects/debian-reiser4/ > >>>> as well as > >>>> https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso > >>>> https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM > >>>> > >>>> Likely the brick/volume feature(s) will be useful in Cloud fabric > >>>> infrastructures, like Google's, where reiser4 excels. > >>>> > >>>> The current SFRN 5.1.3 -patched Zstd -compressed kernel in the > >>>> installation media is Debian's 5.7.10. > >>> > >>> > >>> wow, reiser5 from the box? I might want to try.. > >> Well, it is more of a 'reference implementation' as there are persons > >> who reached out to me because their builds succeeded, they were able > >> to format in reiser4 SFRN x.y.z, but they were not able to mount their > >> partition(s). > >> Turns out, they were inadvertently mixing SFRN 4.0.2 with 5.1.3, > >> either in the reiser4 kernel patch -- released with the same in both > >> instances -- or in the reiser4progs. > > > > > > Yeah, some confusion can take place. Plus unsupported old 4.0.2 > > volumes (a special build with CONFIG_REISER4_OLD=y is required to > > mount them), which is a payment for performance. > > > > > >> > >>> > >>>> > >>>> The installer defaults to create the root system reiser5 -formatted > >>>> partition as: > >>>> mkfs.reiser4 -yo "create=reg42" > >>> > >>> > >>> "reg42" is default profile in reiser4progs-2.0.3 (check by > >>> "mkfs.reiser4 -p") - there is no need to specify it via option. > >> Acknowledged. Thanks. > >> > >>> > >>> Have you had a chance to play with logical volumes (add/remove > >>> bricks, etc)? > >> That is coming up. I still have to create/customize an image of > >> Metztli Reiser4 SFRN5 for a Google Compute Engine (GCE) minimal ~200GB > >> instance for evaluation. > >> Fact is 'not all clouds are created equal' -- even if KVM -based. For > >> instance, reiser4 SFRN 4.0.2 on a trial Linode small ~80GB SSD > >> slice(s) with 2 virtual cpus frequently hung under short sustained > >> disk/network I/O usage. > >> I have not experienced that with reiser4 SFRN 4.0.2 on GCE -- where > >> sometimes I allocate eight to sixteen virtual cpus with 16, 32, or > >> even 64, GBs of RAM, on a region hosting AMD Epyc, for fast kernel > >> building ops. > >> > >> But testing a relatively small bootable image first will usually > >> provide insight if adding one, two... eight, TB slices will make sense > >> later on. > > > > > > I played with your media on a virtual machine. The basic volume > > operations work, however, I guess, adding brick(s) to "/" will cause > > problems at next boot: someone has to register all the bricks before > > mounting "/"... > > > It is important to register all bricks *before* mounting "/", as the > registration procedure collects information need for volume activation > (including transaction replay, etc). > > So at boot time before mounting "/" we need to scan the system and for > each found block device call a brick registration procedure. The problem > is that I don't know what do we actually have before mounting "/". >
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin wrote: > > [...] > > > > > FYI Although not officially, the Debian metaframework Buster AMD64 > > distribution might be the first to support native installation of Reiser4 > > SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system utilities. > > > > I have already made a couple of successful Metztli Reiser4 SFRN 5 native > > installations onto ~100 GB slices, which root file system is formatted in > > 'Reiser5' and 1 GB /boot in JFS. > > https://metztli.it/reiser5 (Screenshot 600x338 size) > > > > The upgraded netboot installation media metztli-reiser4-sfrn5.iso is > > available at: > > https://sourceforge.net/projects/debian-reiser4/ > > as well as > > https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso > > https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM > > > > Likely the brick/volume feature(s) will be useful in Cloud fabric > > infrastructures, like Google's, where reiser4 excels. > > > > The current SFRN 5.1.3 -patched Zstd -compressed kernel in the installation > > media is Debian's 5.7.10. > > > wow, reiser5 from the box? I might want to try.. Well, it is more of a 'reference implementation' as there are persons who reached out to me because their builds succeeded, they were able to format in reiser4 SFRN x.y.z, but they were not able to mount their partition(s). Turns out, they were inadvertently mixing SFRN 4.0.2 with 5.1.3, either in the reiser4 kernel patch -- released with the same in both instances -- or in the reiser4progs. > > > > > The installer defaults to create the root system reiser5 -formatted > > partition as: > > mkfs.reiser4 -yo "create=reg42" > > > "reg42" is default profile in reiser4progs-2.0.3 (check by > "mkfs.reiser4 -p") - there is no need to specify it via option. Acknowledged. Thanks. > > Have you had a chance to play with logical volumes (add/remove > bricks, etc)? That is coming up. I still have to create/customize an image of Metztli Reiser4 SFRN5 for a Google Compute Engine (GCE) minimal ~200GB instance for evaluation. Fact is 'not all clouds are created equal' -- even if KVM -based. For instance, reiser4 SFRN 4.0.2 on a trial Linode small ~80GB SSD slice(s) with 2 virtual cpus frequently hung under short sustained disk/network I/O usage. I have not experienced that with reiser4 SFRN 4.0.2 on GCE -- where sometimes I allocate eight to sixteen virtual cpus with 16, 32, or even 64, GBs of RAM, on a region hosting AMD Epyc, for fast kernel building ops. But testing a relatively small bootable image first will usually provide insight if adding one, two... eight, TB slices will make sense later on. > > Thanks! > Edward. Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Buster w/ Linux 5.7.10 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On Sun, Jul 5, 2020 at 4:13 AM Edward Shishkin wrote: > > > > Â Â Â Â Â Â Â Â Â Â Reiser5: selective file migration. > Â Â Â Â Â Â Â Â Setting/clearing file "immobile" status > > > Earlier any migration of data blocks in reiser5 logical volumes > occurred only in the context of some volume balancing procedure, which > actually is a massive migration, aiming to keep fairness of > distribution on the whole logical volume. Typically such migrations > complete some volume operations, e.g. adding a device to a logical > volume, removing a device from a logical volume, increasing data > capacity of a device, flushing a proxy-device, etc). > > Now user can perform selective data migration. That is, migrate only > data of some specified regular file to any specified device-component > of the logical volume. > > Also, for any specified regular file user can mark it as "immobile", > so that volume balancing procedures will ignore that file. > > Finally, for any specified regular file user can clear its "immobile" > status, so that the file will be movable again by volume balancing > procedures. > > In particular, using this functionality, user is able to push out > "hot" files on any high-performance device (e.g. proxy device) and pin > them there. > > To test the new functionality use reiser4-for-5.7.4.patch of > v5-unstable branch(*) and reiser4progs-2.0.2 (or newer stuff) > > (*) https://sourceforge.net/projects/reiser4/files/v5-unstable/ > > > File Migration: API - > > > /* > Â * Migrate file to specified target device. > Â * @fd: file descriptor > Â * @idx: serial number of target device in the logical volume > Â */ > > /* > Â * Provide correct path here. > Â * This header file can be found in reiser4 kernel module, or > Â * reiser4progs sources > Â */ > #include "reiser4/ioctl.h" > > struct reiser4_vol_op_args args; > memset(, 0, sizeof(args)); > args.opcode = REISER4_MIGRATE_FILE; > args.val = idx; > result = ioctl(fd, REISER4_IOC_VOLUME, ); > > > -- > > > COMMENT. After ioctl successful completion the file is not necessarily > written to the target device! To make sure of it, call fsync(2) after > successful ioctl completion, or open the file with O_SYNC flag before > migration. > > COMMENT. File migration is a volume operation (like adding, removing a > device to/from a logical volumes), and all volume operations are > serialized. So, any attempt to migrate a file, while performing other > operation on that volume will fail. If some file migration procedure > fails (with EBUSY, or other errors), or was interrupted by user, then > it should be repeated in the current mount session. File migration > procedures interrupted by system crash, hared reset, etc) should be > repeated in the next mount sessions. > > > -- Set file immobile status: API - > > > /* > Â * Set file "immobile". > Â * @fd: file descriptor > Â */ > > /* > Â * Provide correct path here. > Â * This header file can be found in reiser4 kernel module, or > Â * reiser4progs sources > Â */ > #include "reiser4/ioctl.h" > > struct reiser4_vol_op_args args; > memset(, 0, sizeof(args)); > args.opcode = REISER4_SET_FILE_IMMOBILE; > result = ioctl(fd, REISER4_IOC_VOLUME, ); > > COMMENT. The immobile status guarantees that any data block of that > file won't migrate to another device-component of the logical volume. > Note, however, that such block can be easily relocated within device > where it currently resides (once the file system finds better location > for that block, etc). > > > -- > > > NOTE: All balancing procedures, which complete device removal, will > ignore "immobile" status of any file. After device removal successful > completion all data blocks of "immobile" files will be relocated to > the remaining devices in accordance with current distribution policy. > > NOTE: Any selective file migration described above will ignore > "immobile" status of the file! So the "immobile" status is honored > only by volume balancing procedures, completing some operations such > as adding a device to the logical volume, changing capacity of some > device or flushing a proxy device. > > > - Clear File immobile status: API > > > /* > Â * Clear file "immobile" status. > Â * @fd: file descriptor > Â */ > > /* > Â * Provide correct path here. > Â * This header file can be found in reiser4 kernel module, or > Â * reiser4progs sources > Â */ > #include "reiser4/ioctl.h" > > struct reiser4_vol_op_args args; > memset(, 0, sizeof(args)); > args.opcode = REISER4_CLR_FILE_IMMOBILE; > result = ioctl(fd, REISER4_IOC_VOLUME, ); > > > -- > > > NOTE: Selective file migration can make your distribution unfair! >
Re: PROBLEM: IO lockup on reiserfs FS.
On Wed, Aug 5, 2020 at 5:01 PM wrote: > On Wed, 5 Aug 2020 12:51:41 -0700 > Linus Torvalds wrote: > > On Wed, Aug 5, 2020 at 9:53 AM wrote: > > > > > > It's been over 1 week since I sent this into the reiserfs-devel > > > mailing list. I'm escalating this as the kernel docs recommend. > > > I'm still willing to help debug and test a fix for this problem. > > > > The thing is, you're using an ancient 4.14 kernel, > > Sorry, I didn't realize kernel development went that fast. > I did try to go to the 5.X series, but the AMDGPU drivers don't work on > my SI card anymore (I need to bisect which takes time and many re-boots > to find the problematic commit). > I'll try the Radeon-SI driver and see if I can reproduce this reliably. > > > and a filesystem > > that isn't really maintained any more. You'll find very few people > > interested in trying to debug that combination. > > > > You *might* have more luck with a more modern kernel, but even then > > ... reiserfs? > > > >        Linus > > > > Why does no one (I've met others who share a similar sentiment), like > reiserfs? Could be because 'others' are all 'virtuous' individuals, employed by 'virtuous' corporations, headquartered at 'virtuous' western countries, whose 'virtuous' governments are able to finance the finest hasbara...er, propaganda, that a corporatocracy...er, 'democracy', can buy. > I'm not looking for fight, I'm incredulous. It's a great FS > that survives oops-es, power failures, and random crashes very very well. > It's the only FLOSS FS with tail packing. On a more sober note, Reiser4, Software Framework Release Number (SFRN) 4.0.2, is stable, and supercedes the features you appreciate in reiserfs, like Edward stated in his subsequent reply. > > Thanks, > David Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Buster w/ Linux 5.5.19 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Re: [GIT PULL][PATCH v5 0/8] Add support for ZSTD-compressed kernel and initramfs
On Mon, Jun 1, 2020 at 2:59 PM Norbert Lange wrote: > > The series seems to be stuck in limbo, and I got the hint to bring > this to Andrew's attention [1]. > Hope this will finally end in upstream, been using these patches for ~2 years. > > Regards, Norbert > > [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955469 Began using your patch for Debian Buster backport of 0.136 initramfs-tools, and Nick Terrel's kernel patch for 5.6 -- but modified for 5.5.17-19 in my reiser4 builds -- and set both defaults to zstd. Thus far, as long as there exists 'a priori' the Zstd package, the combination works in both local and my custom Google cloud instances installations. Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Buster w/ Linux 5.5.19 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
PATCH for libguestfs: tools for accessing and modifying virtual machine disk images
Niltze all- Enabled reiser4 in libguestfs 1.40.2 < http://libguestfs.org/ > since my Virtual Machines are formatted in reiser4. Limited testing, though, as I only made sure I could peek into a VirtualBox VDI image, i.e., guestfish --ro -i -a metztli-reiser4.vdi Given the fact that "man 2 statfs" did not provide a REISER4_SUPER_MAGIC 0x52345362 entry, (heck, entry is blacklisted in Debian, etc. *all* GNU / Linux's "man 2 statfs", /usr/include/linux/magic.h, coreutils' src/fs.h, libguestfs-1.40.2/gnulib/lib/fts.c, etc., WHY!?) I created my own statfs(2) for reiser4 man page in html: short link: https://metztli.blog/index.php/amatl/aP3 long link: https://metztli.blog/index.php/amatl/reiser-nahui/adding-reiser4_super_magic-to-man-2-statfs It would be cool, though, if that reiser4 MAGIC string was included in < https://www.kernel.org/doc/man-pages/ > (thanks in advance for your consideration) The first patch applies against libguestfs 1.40.2 source; the second patch applies against Debian packaging for libguestfs 1.40.2 from < https://packages.debian.org/bullseye/libguestfs-tools > Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Buster w/ Linux 5.2.17 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/ metztli-libguestfs-1.40.2-for-reiser4.patch Description: Binary data metztli-libguestfs-1.40.2-reiser4-enabling-debian-packaging-for-libguestfs-1.40.2.patch Description: Binary data
Re: Reiser4 Linux 4.17.19-1 hangs in Google cloud VM, too.
On Mon, Oct 22, 2018 at 8:38 PM Al Viro wrote: > > On Mon, Oct 22, 2018 at 03:19:12AM -0700, Metztli Information Technology > wrote: > > I installed reiser4 -enhanced Linux kernel 4.17.19-1 --thus replacing the > > prior hung reiser4 -patched kernel 4.18.15-1 in the Google Compute Engine > > (GCE) cloud instance. After less than 24 hours the 4.17.19-1 hung in > > similar way to the 4.18.15-1. > > > > Please note that I had been running my custom Metztli Reiser4 Debian > > Stretch image with reiser4 linux 4.14.20-1 without issues for several months > > < https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20 > > > --until I decided to upgrade to newer kernel(s). > > Er... Does anybody maintain reiser4 these days? I can't recall a single mail > along the lines of "such-and-such VFS/VM/scheduler/etc. change would break > reiser4" > in quite a few years (more than a decade, most likely)... Issue has been mostly resolved (Thanks to Mr. Edward Shishkin -- reiser4 developer) < https://sourceforge.net/projects/reiser4/ > Specifically at: < https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/ > *yet* digging deeper, hang issues in Reiser4/Zstd transparent compression were in large part due to a downstream change in the kernel configuration, i.e., Debian packaging for Linux kernel 4.14.xy, had this default setting in linux/debian/config/config: # CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set However, in Debian packaging for Linux kernel 4.15.xy, and up to current 4.20.xy, default in linux/debian/config/config was changed to: CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y *That* change was causing my Debian reiser4 stretch-backports for AMD64 kernel builds most of the issues that I described. Specifically *this* setting (reprinted again below for emphasis): CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y in a reiser4-patched kernel Debian node hosting [a] type 2 hypervisor VirtualBox directly caused a range of my VirtualBox 5.2.x to 6.0.x successful builds to *hang* their VMs during formatting/executing in reiser4 instances of 2TB root fs slices. Further, it caused corruption of VirtualBox previously built virtual machines which root fs was reiser4. Modifying setting in downstream Debian Packaging for Linux kernel configuration as: CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=n in linux/debian/config/config , my subsequent kernel builds in my development environment fixed most of the issues that made me reach out for help: % uname -a Linux huitzilopochtli 4.20.0-1+reiser4.0.2-amd64 #1 SMP Debian 4.20.4-1+reiser4.0.2 (2018-12-26) x86_64 GNU/Linux Thank you, Al. Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Stretch w/ Linux 4.20 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Reiser4 Linux 4.17.19-1 hangs in Google cloud VM, too.
I installed reiser4 -enhanced Linux kernel 4.17.19-1 --thus replacing the prior hung reiser4 -patched kernel 4.18.15-1 in the Google Compute Engine (GCE) cloud instance. After less than 24 hours the 4.17.19-1 hung in similar way to the 4.18.15-1. Please note that I had been running my custom Metztli Reiser4 Debian Stretch image with reiser4 linux 4.14.20-1 without issues for several months < https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20 > --until I decided to upgrade to newer kernel(s). Below is the relevant section for 4.17.19-1 --remotely obtained by serial output: [91343.247237] INFO: task kworker/u2:1:2363 blocked for more than 120 seconds. [91343.254373] Not tainted 4.17.0-3+reiser4.0.2-amd64 #1 Debian 4.17.19-1+reiser4.0.2 [91343.262590] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [91343.270536] kworker/u2:1D0 2363 2 0x8000 [91343.276151] Workqueue: writeback wb_workfn (flush-8:0) [91343.281409] Call Trace: [91343.284039] ? __schedule+0x3dc/0x860 [91343.287817] schedule+0x32/0x80 [91343.291078] io_schedule+0x12/0x40 [91343.294673] __lock_page+0x119/0x160 [91343.298395] ? page_cache_tree_insert+0xe0/0xe0 [91343.303155] write_jnodes_to_disk_extent+0x373/0x510 [reiser4] [91343.309117] ? zlook+0x15/0x70 [reiser4] [91343.313186] ? utmost_child_internal+0x45/0x80 [reiser4] [91343.318630] write_jnode_list+0x7f/0xb0 [reiser4] [91343.323470] reiser4_write_fq+0x81/0x230 [reiser4] [91343.328516] ? longterm_unlock_znode+0xbf/0x2a0 [reiser4] [91343.334056] flush_current_atom+0x3ae/0x8a0 [reiser4] [91343.339232] flush_some_atom+0x113/0x530 [reiser4] [91343.344150] reiser4_writeout+0x151/0x230 [reiser4] [91343.349162] reiser4_writeback_inodes+0x9c/0x130 [reiser4] [91343.354774] writeback_sb_inodes+0x8f/0xb0 [91343.359117] __writeback_inodes_wb+0x87/0xb0 [91343.363524] wb_writeback+0x288/0x320 [91343.367304] ? wb_workfn+0x1a9/0x450 [91343.370988] wb_workfn+0x1a9/0x450 [91343.374527] process_one_work+0x177/0x350 [91343.378701] worker_thread+0x4d/0x3c0 [91343.382481] kthread+0xf8/0x130 [91343.385771] ? rescuer_thread+0x350/0x350 [91343.390127] ? kthread_create_worker_on_cpu+0x70/0x70 [91343.395343] ret_from_fork+0x35/0x40 Oct 21 23:25:12 cohuatl kernel: [91343.247237] INFO: task kworker/u2:1:2363 blocked for more than 120 seconds. Oct 21 23:25:12 cohuatl kernel: [91343.254373] Not tainted 4.17.0-3+reiser4.0.2-amd64 #1 Debian 4.17.19-1+reiser4.0.2 Oct 21 23:25:12 cohuatl kernel: [91343.262590] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 21 23:25:12 cohuatl kernel: [91343.270536] kworker/u2:1D0 2363 2 0x8000 Oct 21 23:25:12 cohuatl kernel: [91343.276151] Workqueue: writeback wb_workfn (flush-8:0) Oct 21 23:25:12 cohuatl kernel: [91343.281409] Call Trace: Oct 21 23:25:12 cohuatl kernel: [91343.284039] ? __schedule+0x3dc/0x860 Oct 21 23:25:12 cohuatl kernel: [91343.287817] schedule+0x32/0x80 Oct 21 23:25:12 cohuatl kernel: [91343.291078] io_schedule+0x12/0x40 Oct 21 23:25:12 cohuatl kernel: [91343.294673] __lock_page+0x119/0x160 Oct 21 23:25:12 cohuatl kernel: [91343.298395] ? page_cache_tree_insert+0xe0/0xe0 Oct 21 23:25:12 cohuatl kernel: [91343.303155] write_jnodes_to_disk_extent+0x373/0x510 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.309117] ? zlook+0x15/0x70 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.313186] ? utmost_child_internal+0x45/0x80 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.318630] write_jnode_list+0x7f/0xb0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.323470] reiser4_write_fq+0x81/0x230 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.328516] ? longterm_unlock_znode+0xbf/0x2a0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.334056] flush_current_atom+0x3ae/0x8a0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.339232] flush_some_atom+0x113/0x530 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.344150] reiser4_writeout+0x151/0x230 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.349162] reiser4_writeback_inodes+0x9c/0x130 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.354774] writeback_sb_inodes+0x8f/0xb0 Oct 21 23:25:12 cohuatl kernel: [91343.359117] __writeback_inodes_wb+0x87/0xb0 Oct 21 23:25:12 cohuatl kernel: [91343.363524] wb_writeback+0x288/0x320 Oct 21 23:25:12 cohuatl kernel: [91343.367304] ? wb_workfn+0x1a9/0x450 Oct 21 23:25:12 cohuatl kernel: [91343.370988] wb_workfn+0x1a9/0x450 Oct 21 23:25:12 cohuatl kernel: [91343.374527] process_one_work+0x177/0x350 Oct 21 23:25:12 cohuatl kernel: [91343.378701] worker_thread+0x4d/0x3c0 Oct 21 23:25:12 cohuatl kernel: [91343.382481] kthread+0xf8/0x130 Oct 21 23:25:12 cohuatl kernel: [91343.385771] ? rescuer_thread+0x350/0x350 Oct 21 23:25:12 cohuatl kernel: [91343.390127] ? kthread_create_worker_on_cpu+0x70/0x70 Oct 21 23:25:12 cohuatl kernel: [91343.395343] ret_from_fork+0x35/0x40 [91464.070318] INFO: task kworker/u2:1:2363
Reiser4 Linux 4.17.19-1 hangs in Google cloud VM, too.
I installed reiser4 -enhanced Linux kernel 4.17.19-1 --thus replacing the prior hung reiser4 -patched kernel 4.18.15-1 in the Google Compute Engine (GCE) cloud instance. After less than 24 hours the 4.17.19-1 hung in similar way to the 4.18.15-1. Please note that I had been running my custom Metztli Reiser4 Debian Stretch image with reiser4 linux 4.14.20-1 without issues for several months < https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20 > --until I decided to upgrade to newer kernel(s). Below is the relevant section for 4.17.19-1 --remotely obtained by serial output: [91343.247237] INFO: task kworker/u2:1:2363 blocked for more than 120 seconds. [91343.254373] Not tainted 4.17.0-3+reiser4.0.2-amd64 #1 Debian 4.17.19-1+reiser4.0.2 [91343.262590] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [91343.270536] kworker/u2:1D0 2363 2 0x8000 [91343.276151] Workqueue: writeback wb_workfn (flush-8:0) [91343.281409] Call Trace: [91343.284039] ? __schedule+0x3dc/0x860 [91343.287817] schedule+0x32/0x80 [91343.291078] io_schedule+0x12/0x40 [91343.294673] __lock_page+0x119/0x160 [91343.298395] ? page_cache_tree_insert+0xe0/0xe0 [91343.303155] write_jnodes_to_disk_extent+0x373/0x510 [reiser4] [91343.309117] ? zlook+0x15/0x70 [reiser4] [91343.313186] ? utmost_child_internal+0x45/0x80 [reiser4] [91343.318630] write_jnode_list+0x7f/0xb0 [reiser4] [91343.323470] reiser4_write_fq+0x81/0x230 [reiser4] [91343.328516] ? longterm_unlock_znode+0xbf/0x2a0 [reiser4] [91343.334056] flush_current_atom+0x3ae/0x8a0 [reiser4] [91343.339232] flush_some_atom+0x113/0x530 [reiser4] [91343.344150] reiser4_writeout+0x151/0x230 [reiser4] [91343.349162] reiser4_writeback_inodes+0x9c/0x130 [reiser4] [91343.354774] writeback_sb_inodes+0x8f/0xb0 [91343.359117] __writeback_inodes_wb+0x87/0xb0 [91343.363524] wb_writeback+0x288/0x320 [91343.367304] ? wb_workfn+0x1a9/0x450 [91343.370988] wb_workfn+0x1a9/0x450 [91343.374527] process_one_work+0x177/0x350 [91343.378701] worker_thread+0x4d/0x3c0 [91343.382481] kthread+0xf8/0x130 [91343.385771] ? rescuer_thread+0x350/0x350 [91343.390127] ? kthread_create_worker_on_cpu+0x70/0x70 [91343.395343] ret_from_fork+0x35/0x40 Oct 21 23:25:12 cohuatl kernel: [91343.247237] INFO: task kworker/u2:1:2363 blocked for more than 120 seconds. Oct 21 23:25:12 cohuatl kernel: [91343.254373] Not tainted 4.17.0-3+reiser4.0.2-amd64 #1 Debian 4.17.19-1+reiser4.0.2 Oct 21 23:25:12 cohuatl kernel: [91343.262590] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 21 23:25:12 cohuatl kernel: [91343.270536] kworker/u2:1D0 2363 2 0x8000 Oct 21 23:25:12 cohuatl kernel: [91343.276151] Workqueue: writeback wb_workfn (flush-8:0) Oct 21 23:25:12 cohuatl kernel: [91343.281409] Call Trace: Oct 21 23:25:12 cohuatl kernel: [91343.284039] ? __schedule+0x3dc/0x860 Oct 21 23:25:12 cohuatl kernel: [91343.287817] schedule+0x32/0x80 Oct 21 23:25:12 cohuatl kernel: [91343.291078] io_schedule+0x12/0x40 Oct 21 23:25:12 cohuatl kernel: [91343.294673] __lock_page+0x119/0x160 Oct 21 23:25:12 cohuatl kernel: [91343.298395] ? page_cache_tree_insert+0xe0/0xe0 Oct 21 23:25:12 cohuatl kernel: [91343.303155] write_jnodes_to_disk_extent+0x373/0x510 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.309117] ? zlook+0x15/0x70 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.313186] ? utmost_child_internal+0x45/0x80 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.318630] write_jnode_list+0x7f/0xb0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.323470] reiser4_write_fq+0x81/0x230 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.328516] ? longterm_unlock_znode+0xbf/0x2a0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.334056] flush_current_atom+0x3ae/0x8a0 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.339232] flush_some_atom+0x113/0x530 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.344150] reiser4_writeout+0x151/0x230 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.349162] reiser4_writeback_inodes+0x9c/0x130 [reiser4] Oct 21 23:25:12 cohuatl kernel: [91343.354774] writeback_sb_inodes+0x8f/0xb0 Oct 21 23:25:12 cohuatl kernel: [91343.359117] __writeback_inodes_wb+0x87/0xb0 Oct 21 23:25:12 cohuatl kernel: [91343.363524] wb_writeback+0x288/0x320 Oct 21 23:25:12 cohuatl kernel: [91343.367304] ? wb_workfn+0x1a9/0x450 Oct 21 23:25:12 cohuatl kernel: [91343.370988] wb_workfn+0x1a9/0x450 Oct 21 23:25:12 cohuatl kernel: [91343.374527] process_one_work+0x177/0x350 Oct 21 23:25:12 cohuatl kernel: [91343.378701] worker_thread+0x4d/0x3c0 Oct 21 23:25:12 cohuatl kernel: [91343.382481] kthread+0xf8/0x130 Oct 21 23:25:12 cohuatl kernel: [91343.385771] ? rescuer_thread+0x350/0x350 Oct 21 23:25:12 cohuatl kernel: [91343.390127] ? kthread_create_worker_on_cpu+0x70/0x70 Oct 21 23:25:12 cohuatl kernel: [91343.395343] ret_from_fork+0x35/0x40 [91464.070318] INFO: task kworker/u2:1:2363
