fpsync: Colorize output
Changelog: write explicitly about log *files*
fpsync: Run resuming - Rework commit b853b77d
fpsync: cleanup variable names
fpsync: homogenize QMGR messages
fpsync: only display kill messages once when pressing CTRL-C
fpsync: typos in comments
fpsync: use explicit -p option for ps
fpsync: Run resuming - Rework commit 686edde
fpsync: fix wrong jobs rescheduled when resuming a run (option -r)
fpsync: Remove useless '-f' option in mv command
TODO: Update
Debian: add reference to pax(1) in control file
fpsync: cleanup logs when replaying a run
fpsync: improve startup logs
fpsync: rename main log file to fpsync.log
fpsync: improve .ret files filtering
fpsync: fix failure detection for piped tools
fpsync: rework final report
fpsync: rework return code handling
Doc: Add a link to Utah's CHPC website
Doc: Update Changelog following pax(1) tool support
Doc: Update SILL link
fpsync: Document pax tool
fpsync: Add preliminary support for pax(1) tool
doc: Man pages fixes
fpsync: Log job PIDs in -vvv mode
Doc: Add a few words to insist on the fact the fpart only reads data
TODO: Add idea
Debian: Bump Standards-Version in debian/control
fpsync: check for common commands/tools presence (GH issue #47)
Update Debian package
man/fpart.1: Fix typo
WWW: Fix typo (capital)
Release version 1.6.0
WWW: Fix Macstadium URL
WWW: Add a note about Debian Almquist shell (dash)
WWW: Add a note about TAR_NAME following c3e5af0
fpsync: Facilitate tar tool change on Solaris-based OS
WWW: Update links
Bump copyright dates
Update TODO
Website: mention Github sponsors page
README: mention Github sponsors page
fpsync: Avoid returning "" from total_*_count() when run.meta file does not exist
fpsync: Show summary after fpart pass
fpsync: Limit useless log generation by removing empty log files
Doc: Add precisions about tested OS versions
Doc: add new links
On 10/24/23 18:57, Fab11 wrote: Hello there, I increased parts number from 1000 to 10000 but it was still way faster to generate. I then moved to 100000 and it looks to suit better. In the worst case, the last part was generated just an hour before the end of the sync (half an hour on average) for a 7h to 9h job duration. Difficult to say if it was quicker and how much because it was a second pass anyway. So a big part of the time rsync took to copy files in the first pass was not spent again during...
TODO: add ideas brought by Fab11 on SF
fpsync: Speed up total counts in SIGINFO handler
Hello, Sorry to come back with a reply so late. I increased parts number from 1000 to 10000 but it was still way faster to generate. I then moved to 100000 and it looks to suit better. In the worst case, the last part was generated just an hour before the end of the sync (half an hour on average) for a 7h to 9h job duration. Difficult to say if it was quicker and how much because it was a second pass anyway. So a big part of the time rsync took to copy files in the first pass was not spent again...
Update TODO
fpart: add missing free(env_fpart_parterrno_string)
fpart: add new hook variable: FPART_TOTALNUMPARTS
fpart: add post-run hook (option -R)
fpart: Add total_num_parts to main_status
fpart: Introduce main_status to track total size and files
fpart: add two new hook variables: FPART_TOTALSIZE and FPART_TOTALNUMFILES
Hello, I will try that and let you know. You are welcome for the ideas :) Thanks for your consideration. Best regards.
On Tuesday, July 25, 2023 3:52:17 PM CEST Fab11 wrote: Hello, Many thanks for your detailed answer! You're welcome :) You confirmed 1000 files is not enough, it's my opinion too. I realised that while looking at the top command output frequently. Parts files number passed on the command line to fpsync were way ahead of the last generated one, meaning fpart was faster generating parts than rsync running them. I will maybe try to generate bigger parts for intermediate runs. Yes, that's the way to go,...
Hello, Many thanks for your detailed answer! You confirmed 1000 files is not enough, it's my opinion too. I realised that while looking at the top command output frequently. Parts files number passed on the command line to fpsync were way ahead of the last generated one, meaning fpart was faster generating parts than rsync running them. I will maybe try to generate bigger parts for intermediate runs. Another question regarding jobs (thanks for the details on the usage). I was wondering what would...
On Wednesday, July 19, 2023 8:52:32 PM CEST Fab11 wrote: Hello, Sorry for my delayed answer, I am just back from holidays :p [...] 1) To not wait for big lists to be generated by fpart and start rsync right away, I set fpsync to use parts of 1000 files (-f). But I realised the number of parts is very huge (45,000+). I have to say data are spreaded on several 8 TB volumes, processed one at a time and one after the other. The server running the jobs has 48 cores and fpsync is setup to run 24 parallel...
Hello, I have to migrate a large amount of data to a new storage array (around 100 TB), which is mostly composed of small files (max 100 KB) located into a 7 directory deep structure. The transfert to the new storage array has to be achieved through a SMB/CIFS share. So, Samba and small files, the worst case scenario... Using rsync or robocopy would take ages. I discovered fpart and fpsync by accident and it turned out to be the magic solution according to my speed tests. It would let me copy these...
fpsync: Remove useless redirection to /dev/null
fpsync: Clarify comments regarding resume flags
fpsync: show transmitted files count / data size in final status and SIGINFO handler
fpsync: fix off-by-n error when calculating ETA in SIGINFO handler
Doc typo
Unbreak Paypal picture and link
Update documentation
fpart: provide long options (for the most important ones)
fpsync/mdoc(7): Ic -> Fl
fpart/mdoc(7): Ic -> Fl
TODO: Add idea
Doc: Improve fpsync description
Fix changelog
doc: Update links and add logos
doc: Update fpsync page following new fpart's option -P
doc: Write about fpart passing Coverity Scan tests
fpart: remove useless NULL check for in_fp
fpart: max_size is signed
fpart/man: Minor fixes
fpart/man: Document option -P
fpsync: fix tar tool on OSX
fpsync: fix directory modification times updates with GNU tar(1)
fpsync: enable fpart's new option -P with cpio(1) and tar(1)
fpart: add parent_path() function
fpart: add option -P (add parent directories before closing partitions)
fpart: fix if_not_realloc() macro
fpart: rename cleanup_path() to cleanslash_path()
Revert ef6b10c - globally ignore SIGTTIN and SIGTTOU
Typo
Update changelog following merge of GH PR #44
Merge pull request #44 from biocyberman/pr
Set OPT_TOOL_PATH in fpsync