Replies: 5 comments
-
Possible explanation: the inode numbers are not stable. Usually they are stable for local linux filesystems, like ext4. They might be unstable across mounts for network file systems. Number of files should roughly correspond to the amount of files in the log (although IIRC borg only counts regular files as files, not directories, symlinks or other file types). Do you see a lot of unexpected "M" status files after a reboot? See the FAQ about this. Maybe edit your top post and add some infos about the OS, borg version, filesystems involved, etc. |
Beta Was this translation helpful? Give feedback.
-
Yes that is correct. Last night I had ~213000 "M" files out of a total of ~319000 total. These files were definitely not modified,
These files were definitely not modified. I've been trying to understand the bit about files-cache. Since I don't set anything I'll assume it uses the default of ctime,size,inode. The FAQ mentions it's problematic for files located on sshfs and similar network file systems which do not provide stable inode numbers. The files inexplicably modified are in fact all stored on a 8TB USB drive. Could that be the problem? Maybe USB drives need to be explicitly unmounted and ejected before reboots? |
Beta Was this translation helpful? Give feedback.
-
It does not matter with which cable you connect the disk, but the filesystem you use. So, what fs do you use on the external disk? Also, in some situations, SMR can be also a reason for slowness, but I guess not in this case (mostly r/o access - maybe check if atime updates are on for the fs). |
Beta Was this translation helpful? Give feedback.
-
https://borgbackup.readthedocs.io/en/stable/faq.html?highlight=inode check that, search for first inode on that page and use the |
Beta Was this translation helpful? Give feedback.
-
It's all EXT4. |
Beta Was this translation helpful? Give feedback.
-
I've noticed that after reboots the backup (i.e. borg create) takes much longer.
Typically a backup takes less than 30 minutes, but after a reboot it takes 12 hours or more.
"Number of files" are always reported as the same ballpark figure, around 300,000 but the number of files listed in the log are at least 10x
more than other days.
I don't think it's a problem, other than the slight inconvenience of the backup running for so long when it happens. Mostly I'm just curious why.
Beta Was this translation helpful? Give feedback.
All reactions