Open rstech209 opened 2 years ago
Well, concerning sparse files in a Firefox profile (point 2), I have to admit that I haven't seen anything in Mozzilla's technical literature referring to it ... The advice for copying profiles never takes this point into consideration. To determine the sparsness of the profile files, I used this link, established by Linux gurus!... And I can see some sparses files in a Firefox profile ... Maybe we shouldn't take this into account too much, maybe not ??
This allowed me to do some tests (overlay mode is not enabled) to copy the profile by comparing the performance of cp
and rsync
(only for first copy):
time cp -a --reflink=auto "$BACKUP"/* "$TMP"
real 0m0,219s
user 0m0,028s
sys 0m0,190s
versus
time rsync -aX --sparse --no-whole-file "$BACKUP/" "$TMP"
(equivalent results for time rsync -aX --inplace --no-whole-file "$BACKUP/" "$TMP"
)
real 0m0,535s
user 0m0,592s
sys 0m0.338s
No contest! => 'cp'
allows to speed up the copy by a factor 2 (and more, depending on the tests) and as a bonus, native support of sparse files.
Here, my profile was "only" 70M, but for a much larger volume of data (with several profiles for example) 'cp' could improve the start of the user session.
Don't you think it would be a good idea to replace rsync
by cp
in this case ?
I believe you'll need to clear the caches between tests or else the 2nd test may artificially complete faster. This can be done by sysctl vm.drop_caches=3
.
The difference is less, but still significant:
sync; sleep 5; echo 3 | sudo tee /proc/sys/vm/drop_caches
time cp -a --reflink=auto "$BACKUP"/* "$TMP"
real 0m3,714s
user 0m0,053s
sys 0m0,357s
sync; sleep 5; echo 3 | sudo tee /proc/sys/vm/drop_caches
time rsync -aX --sparse --no-whole-file "$BACKUP/" "$TMP"
real 0m5,500s
user 0m0,716s
sys 0m0,589s
But of course, resynchronization (destination directory not erased) is more efficient with rsync
sync; sleep 5; echo 3 | sudo tee /proc/sys/vm/drop_caches
time rsync -aX --inplace --no-whole-file "$BACKUP/" "$TMP"
real 0m1,313s
user 0m0,110s
sys 0m0,137s
Seeing the transfer times ... fortunately there are caches !
By experimenting with profile-sync-daemon (overlay mode is not enabled), I realized that some files in my Firefox profile were corrupted (places.sqlite for example). This didn't seem to be too much of a problem for Firefox. 1) In fact, I noticed that the synchronization was very slow (30s to transfer the 100M of my profile) and I started to look for the cause.
rsync
encountered these kind of errors:It seemed to me that such a problem (
rsync
command which generates errors) should be easily detected, without necessarily having to look into the logs. So I forwarded thersync
command lines with an error test and an alert message:Same thing for 'sync' and 'unsync' operations . On the other hand,
notify-send
command (oralert
or something similar) adds a dependency. What other solution for handlingrsync
errors might be possible?2) By searching the issue, I noticed that at the first synchronization, the sparse files were copied like "standard" files.
I tested the sparseness of files (to compare backup directory with "volatile" directory in RAM) with :
I also tried
stat
command to see block used by sparse files.The problem seems to be fixed by changing the following line:
For other synchronizations (resync), the --inplace option seems OK.
Since these tests, I have rebuilt my profile and I no longer see any problem. I don't believe psd is the cause of a profile corruption issue, but have you ever seen anything similar that can result from dealing with sparse files?