Re: Successful first run of 6TB archiving project
John Goerzen <[email protected]> Mon, 17 Jul 2023 09:59:10 -0500
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jul 17 2023, Denis Corbin wrote: > > According to the numbers you provided, dar consumed an average of 998 bytes of > RAM per inode... Ignore my questions if you don't have the info: it would be > interesting to know whether EA and FSA were saved and also whether > parallel/block compression and/or encryption has been used and with how much > threads for each (Multi-thread implementation relies on memory chunks used to > distribute/gather compression work to/from worker threads) Hi Denis, I did note that the RAM usage was higher than documented on the limitations page, but it wasn't so much higher than I went searching for causes. But I'm happy to answer :-) I used no specific options relating to EA or FSA. I would not have expected much of either. The files are all stored on ZFS, but it does seem like there is some degree of FSA stored, somewhat to my surprise. As this isn't an ext* filesystem, I have no idea what it's storing. I saved the summary at the end of archive creation, but it is on a different drive and I'm running a dar -t test right now, so I can grab that a bit later. I do see "Data + FSA(13)" for every file on the dar -v -t output. This was created on dar 2.7.8, from a build before I enabled libthreadar linking, so no parallel features are used. zstd compression is enabled, but the exclude rules mean that the majority of the data by bytes (and probably also by inode) is not being compressed since it is a lot of image and video files. There is no encryption in use, and no rsync sig options in use. dar -q -l on the isolated catalog shows: total number of inode : 1295439 fully saved : 1295439 binay delta patch : 0 inode metadata only : 0 distribution of inode(s) - directories : 67694 - plain files : 1224095 - symbolic links : 3647 - named pipes : 3 - unix sockets : 0 - character devices : 0 - block devices : 0 - Door entries : 0 hard links information - number of inode with hard link : 116267 - number of reference to hard linked inodes: 246019 destroyed entries information 0 file(s) have been record as destroyed since backup of reference /usr/bin/time report on dar -q -l for this catalog: 12.83user 1.02system 0:13.87elapsed 99%CPU (0avgtext+0avgdata 1114820maxresident)k 159715inputs+0outputs (0major+283922minor)pagefaults 0swaps which is a bit less than it was using during -c, but then I'm probably not asking it to do as much with it. Incidentally, in a bit of an echo of a conversation from a little while back, I observe that when I use -q -l on the last slice of an archive, as opposed to an isolated catalog, it will easily report the full size of the archive (including all slices, I believe), while when run on an isolated catalog, it only reports the size of the catalog. By the time this project is done, I may have around 3 million inodes represented. - John