Hello! "Thomas Schmitt" <scdbac...@gmx.net> skribis:
>> Based on this and on a suggestion Ricardo made on IRC, I passed >> “-padding 10m” and that solved the problem. \o/ > > Ouchers. Do all files bear their expected content ? > Especially the last one: /var/guix/db/db.sqlite It looks good, and there are no I/O errors left (I mounted it and run “tar” over it.) Note that the image is now available here: https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz (I haven’t tried smaller padding.) > If so, then something truncates the output stream of libisofs via libburn. > The only component that comes to my mind is the fifo between them. > The default fifo size is 4 MiB. Quite suspicious. > > Try to reduce its size to the minimum by adding these grub-mkrescue > arguments: > > -- -- -fs 64k -padding 64k > > If the fifo is to blame, then a padding of 64k should suffice to protect > the valuable blocks from a premature end. OK, I’ll try to test this, but note that I’ll be largely unavailable for a week. >> the documentation of “-padding” suggests >> that this kind of problem is not uncommon. > > It's normal purpose is to work around a traditional Linux kernel bug: > > CDs written with write type Track-At-Once bear two unreadable blocks at > the end. Most CD drives report these blocks as part of the data range. > When Linux shall read a single block for isofs, it reads a larger chunk. > The chunk is not large enough to reach over the nominal end of the data > range, but it can reach the unreadable end blocks by mistake. > In this case Linux does not only miss the end blocks but also valid > payload blocks which are part of the filesystem. This yields I/O error. > > The developer of cdrecord and the kernel people mistake this problem > for a "fuzziness" of a CD end by at most 2 seconds of audio play time. > This is wrong from reading the specs and from making experiments. > However, cdrecord introduced the tradition to add 150 blocks of padding > which would 2 seconds of sound. > As long as the read chunk of Linux is smaller than that, the padding > protects the operating system from touching the lead-out blocks of the > TAO track. > > This cannot happen on hard disk or any optical media type other than CD. > If you write the CD by Session-At-Once it cannot happen. If you have one > of the rare CD drives which do not count the lead-out blocks to the > readable size of the CD, it cannot happen. (Currently 1 of my 7 drives > tells the truth.) > > But who am i to stand against all others ? > So xorriso, too, adds 300 KiB of padding by default. I see, thanks for explaining! Ludo’.
