On Tue, Oct 23, 2018 at 3:16 PM Edward Shishkin <edward.shishkin@xxxxxxxxx> wrote: > > On 10/23/2018 08:06 AM, Edward Shishkin wrote: > > On 10/23/2018 06:28 AM, Jose R R wrote: > >> Thank you for replying, Al- > >> > >> On Mon, Oct 22, 2018 at 8:38 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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). > > > > Hello. > > > > Looks like a regression because of VFS/block-layer changes (I don't > > test new releases carefully enough). Once I am back from vacations, > > I'll have a look at this.. > > > > > > I don't confirm any regression though. Most likely it's the old bug > (slow progress in committing a transaction), which is not always > reproducible. See (*) for example. One needs to add profiling and > accumulate statistics to understand what is wrong. Personally for me > it is not a task of high priority. Fact of matter, Sir, is that *something* changed in upstream kernel source development that has rendered your reiser4 patches for Linux 4.17.x --and which continues into 4.18.y series-- unusable. For instance, in my local development 1.3TB machine, reiser4 enhanced Linux 4.18.11/12/13/15 hung so frequently and so bad that I had to turn off the machine as many times. I did not lose data in my reiser4 1.3TB root fs partition *notwithstanding* in one instance I had to reformat the ext2 boot partition because hung instance /turn off machine/ reboot, corrupted one of GRUB files and I was unable to delete it. Accordingly, the serial output provided from my custom Google cloud hung instances of both 4.17.x and 4.18.y is all I can provide --hoping it may elucidate a clue. This hung issue is more serious than what you are assuming, Ed. Notwithstanding, the hung failure pattern may be familiar to other kernel developers interacting with the upstream source that triggered such an output -- although initially I was not sure if it was reiser4 per se -- hence my decision to ask for help at those lists. > > My advise: don't -cc any mailing lists different from reiserfs-devel: > they are not able to magically resolve your problems. You will get > a flow of negatives instead. I am used to 'negatives', Sir. It is a way to wean out the imbeciles from a project and has the potential to attract open minded individuals ;-) On the plus side *they* already know that reiser4 kernel development has not stopped. > > (*) https://sourceforge.net/p/reiser4/tickets/1/ > > Thanks, > Edward. > Apropos, noticing that reiser4 -patched kernel 4.16.xy runs solidly, I further modified its vanilla Debian packaging (wrapper) to accept the string '+reiser4.0.2' appended, as: uname -v #1 SMP Debian 4.16.18-2+reiser4.0.2 (2018-10-23) --when I first wrapped that particular kernel series build with its corresponding vanilla Debian packaging some months ago, it refused to accept *that* string ;-) Once at it, I also removed Btrfs support: < https://sourceforge.net/projects/metztli-reiser4/files/Reiser4-SFRN-4.0.2_Linux-4.16.18-2-EOL_for-Stretch/ > For me this is the last usable reiser4 -patched kernel, Mr. Shishkin. If that *serious* anomaly affecting reiser4 for 4.17.x and 4.18.y series is not resolved, I doubt that the next Linux kernel 4.19.st and 4.20.uv series will be any better. Thus, the main reason I was asking for help outside this mailing list. > > > >> That link you referenced is just my hack for the corresponding Debian > >> kernel packaging (wrapper) to build 'Reiser4 the Debian Way', i.e, > >> generating reiser4 module & kernel -- suitable for installation media > >> -- in addition to Debian'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)... > >> This is the actual patch for the Linux 4.14.xy series: > >> < > >> https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/reiser4-for-4.14.1.patch.gz/download > >> And yes, Mr. Edward Shishkin, still develops/maintains reiser4, > >> please see: > >> < https://github.com/edward6/reiser4 > > >> > >> I have a couple of reiser4 custom Google Compute Engine (GCE) cloud > >> instances which have been running LAMP for a while. One of them runs > >> reiser4 -enabled Linux kernel 4.15.x whereas the other one was running > >> 4.14.x (both for several months/years already) until I decided to > >> upgrade the 4.4.20-1 to newer reiser4 -enabled kernels. By the way > >> this last kernel that I installed: > >> uname -a > >> Linux cohuatl 4.16.0-2+reiser4.0.2-amd64 #1 SMP Debian 4.16.18-2 > >> (2018-06-27) x86_64 GNU/Linux > >> > >> seems to be performing nicely --if things continue fine I can assume > >> that the drastic change affecting reiser4 hacked kernels occurred > >> beginning with upstream Linux series 4.17.x and on... > >> > >> > >> Best Professional Regards. > >> > > > Thanks. -- Jose R R http://metztli.it --------------------------------------------------------------------------------------------- Download Metztli Reiser4: Debian Stretch w/ Linux 4.16 AMD64 --------------------------------------------------------------------------------------------- feats ZSTD compression https://sf.net/projects/metztli-reiser4/ ------------------------------------------------------------------------------------------- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
