Re: [Bug-xorriso] bug with handling symbolic links?

[Thomas Schmitt]

Hi,

> Identical files have different dev_t  but the same ino_t (physically stored
> in the same location) -

This is the base for the incremental backup decisions by
-disk_dev_ino "ino_only".


> which lead me to conclude that they are subject to hardlinks processing with
> -hardlinks on. Is that correct?

Rather not.

-hardlinks looks inside the composed ISO directory tree
for families of file paths of which the input files on
"hard disk" share the same dev_t and ino_t. These families
will share a Rock Ridge PX inode number in the ISO. This
Rock Ridge inode number is ignored at least by Linux, FreeBSD,
and NetBSD. But xorriso may restore the families to hardlinks
which share dev_t, ino_t and file content.

Since dev_t on hard disk differs, the files in a snapshot
are not linked with those in another snapshot, even if both
snapshots would go into the same backup.


> For the image generation described above, -for_backup consumes >250MB of
> swap (in addition to the 512MB RAM) quite early (i.e. during first -add), 
> whereas -acl on -xattr on -md5 only swaps later (i.e. during the subsequent
> -update_r) and much more moderately (~30 MB),

Wow. That's unexpected.

But on the other hand, ten million file entries are a lot.
220 MB of extra consumption would mean only 22 bytes per
file.

I will investigate. But it might be the natural cost of
checking 10 million files for hard links.

How much deduplication is provided by hardlinks in your
file tree ?
Would it be worth to look for hardlinks, so that at restore
time the data will not grow over the original size and the
proper link relations are maintained ?


Before i make own experiments on smaller scale:

Why/how do you combine -add and -update_r in the same run ?

-add causes files to be copied into the ISO unconditionally,
whereas -update_r takes only those which have no matching
counterpart in the loaded ISO.

Can you show me the arguments of your xorriso run ?


Have a nice day :)

Thomas