Bug 7885 - rsync fills the disk blocking the system
Summary: rsync fills the disk blocking the system
Status: RESOLVED WONTFIX
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: x86 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-23 19:16 UTC by giampaolo ferradini
Modified: 2011-03-08 07:48 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description giampaolo ferradini 2010-12-23 19:16:00 UTC
in a situation where rsync was instructed to sync a home directory tree with a second hard drive normally mounted in /media, the command executed even if no such drive was mounted and filled the main drive completely, preventing the system from booting.

i would like to draw a few issues to attention:
- rsync should have a check that prevents it from making the disk unusable, i.e. from filling it to the point of disrupting the boot process;
- i would recommend a "check space required" and confirmation request in case space is not sufficient to complete the task;
- in case a /media folder is involved, i would suggest a confirmation request in case there is no volume currently mounted, to prevent rsync from creating undesired directories.

kindest regards

(error seen under fedora 14)
Comment 1 Wayne Davison 2011-01-01 14:03:24 UTC
Assigning special meaning to /media differs by OS, and is not something that rsync should handle.  A backup script that is going to use rsync should definitely check if the path it is going to use is properly mounted first.

Not overflowing a destination disk is a difficult problem to handle in an efficient manner, since (1) we don't know how much space we need when we start, (2) other processes could be using space during our run, making an initial check inaccurate, (3) block sizes inefficiencies and directory-space requirements are hard to compute, and (4) the destination tree may be split over multiple volumes.  One potential solution might be to have a command-line option that would tell rsync to check specific mount points at specific intervals and exit if below a given percent.  However, such a check idiom might be better written as a helper script that could be used to run rsync, regularly check the destination filesystems via df, and kill rsync should space requirements diminish below desired levels.  If someone would like to write such a helper script, I'd be glad to include it in the contrib directory.
Comment 2 giampaolo ferradini 2011-03-08 07:48:01 UTC
(In reply to comment #1)
> Assigning special meaning to /media differs by OS, and is not something that
> rsync should handle.  A backup script that is going to use rsync should
> definitely check if the path it is going to use is properly mounted first.
> 
> Not overflowing a destination disk is a difficult problem to handle in an
> efficient manner, since (1) we don't know how much space we need when we start,
> (2) other processes could be using space during our run, making an initial
> check inaccurate, (3) block sizes inefficiencies and directory-space
> requirements are hard to compute, and (4) the destination tree may be split
> over multiple volumes.  One potential solution might be to have a command-line
> option that would tell rsync to check specific mount points at specific
> intervals and exit if below a given percent.  However, such a check idiom might
> be better written as a helper script that could be used to run rsync, regularly
> check the destination filesystems via df, and kill rsync should space
> requirements diminish below desired levels.  If someone would like to write
> such a helper script, I'd be glad to include it in the contrib directory.

thank you for your reply, and sorry for my late reply to it.
unfortunately i am definitely too unexperienced to write that kind of script.
but if you have examples or references for the single bits, i'd certainly be willing to play with it.