On Sat, Aug 29, 2020 at 2:54 AM Edward Shishkin <edward.shishkin@xxxxxxxxx> 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 > >> <edward.shishkin@xxxxxxxxx> 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 "/". > > Brick registration can be performed by calling "volume.reiser4 -g". > However, it accepts device name, that we obviously don't have, as all > the names are in "/", which is not yet mounted. > > I guess that solution exists (and possibly locates in initrd), because, > it is perfectly possible to boot e.g. with root over LVM (a special > utility scans the system and collects information about devices- > components of the logical volume). Any ideas? man initramfs-tools Under debian there are: /etc/initramfs-tools/hooks/ /usr/share/initramfs-tools/hooks/ Observing the latter, we can see that it contains executable scripts for reiserfs, lvm2, etc.; hence, every time an update-initramfs command is performed to create/update an initrd.img-`uname -r` these scripts are bundled into the initrd image. An executable script, i.e., named reiser5, might also be added to perform the 'brick registration procedure', then subsequently running update-initramfs for its inclusion into the initrd image. > > 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/
