On 05/28/2019 06:26 PM, Thanatermesis wrote:
> Hello Edward,
Hello.
>
> I was thinking since then about the "du" issue, and i still trying to
understand myself how much relevant could be that the "du" tool doesn't
reports the correct information, so I have a lot of tools (scripts) that
relies on this information, for example:
>
> * video & audio converters (shrinkers) that if the converted file is
bigger than the original (info give by "du"), it will copy back the
original one
Actually, it is very-very strange that they rely on "implementation"
rather than on size reported by standard tools (stat(2), etc).
Please, double check it, if possible.
Also we need to strongly discourage users from placing ISO images as
well as other large "media-files" to compressed reiser4 partitions. For
other ones (with disabled compression) du(1) reports correct values.
> * report tools, like downloading an ISO and verifying its correct size
Ditto.
Who is really needs to know how much space a file occupied on disk is
quota(1) and friends..
>
> so, is there a way to make "du" to give the correct information?
maybe as a mount option for reiser4? mmh...
Yes, it possible - we need to update i_blocks and i_bytes right after
the moment when compression happened and
make inode dirty (the last one leads to performance drop).
>
> Apart of that, I have sucessfully integrated reiser4 natively in the
alpha versions of elive :), everything seems to work pretty well,
included in the installer by default and can be used to install on
reiser4, if you want to play with the Live iso you can get it from here:
https://eliveisos.elivecd.org/betatest/ so you can use it as a
"recovery" reiser4 tool or just to make "debian buster" installs with a
default FS in reiser4, with optimized settings for different hardware
profiles / ssd / etc whohooo!
Cool, I have cc-ed the mailing list for this news.
>
> Now, I have a bug report about reiser4, I have seen it after one of
common users of elive used reiser4 for its installs, and had a problem
trying to make working dropbox (if you didn't know, dropbox only accepts
ext4 filesystem to run), so i wrote for him a howto about how to create
a file image on his system, format it to ext4, and mount it to be used
for dropbox... everything worked correctly, but it failed after his
reiser4 install
>
> More exactly, seems like reiser4 is unable to mount loopback devices
in RW mode, I have attached you a screenshot of some commands and
results of this behaviour
Ok, I'll try to reproduce it and to have a look..
>
> By other side, you may problably know that grub doesn't get the UUID
of the reiser4 devices, and fallbacks to non-uuid assigned values like:
root=/dev/sda3, this ends in a non-booting system sometimes (installed
in live mode, where the HD is sdb and the live device is sda, then the
system boots without the live mode and so sdb turns to be sda, boot fails)
>
> So I was able to fix this grub issue with a very simple and small
patch, that gets correctly the UUID in case its not get, you may
probably want to publish it in the wiki :)
I'll make a note in "getting started" section.
Thanks!
Edward.
>
> Patch attached too, tested and working, it should at least apply to
the "grub-common" package from debian-buster, but is very easy to create
a new one based on it, or used as a reference
>
>
> Regards!
> Thanatermesis
>
>
>
>
> El dom., 19 may. 2019 a las 16:43, Edward Shishkin
(<edward.shishkin@xxxxxxxxx>) escribió:
>
> On 05/19/2019 01:57 PM, Thanatermesis wrote:
> > 1) this is because it shows the real size of the data (not
compressed)
> > or because there's a kinda bug with that? i wonder why "du" doesn't
> > reports the correct value
>
> du(1) relies on values stored in the fields i_bytes, i_blocks of
vfs's
> struct inode.
> Reiser4 simply doesn't support those fields on-line and they contain
> garbage.
> Their proper on-line support leads to ~30% performance drop (for
HDD disks).
>
> Fsck supports it off-line however: you can unmount your
partition, run
> fsck.reiser4 --fix /dev/xxx - it will set correct values for i_size,
> i_blocks,
> mount again (better read-only). Then du(1) will show correct
statistics
> (based on sizes of squeezed files).
>
> Thanks,
> Edward.
