While backing up some data (a 200 GB home directory) with rsync, I got an I/0 error for a particular file, after which rsync continued on "normally" with its backup. The problem source file showed as having a file size of 72 bytes.

I cancelled rsync, and ran the same command again. This time that same file showed to be transferring data.. lots of data ...and more data, and more... I checked the destination file's size, and it was up to 13 GB! so I used Ctrl-c to cancel rsync.

On checking the source file size again, in Nautilus, it showed a size of 60.0 PB (Peta Bytes!) on a 500 GB drive.

Now, the main point of all this: Would/could deleting this file cause loss of data in other files, seeing that the file system can perceive it to be much bigger than it actually is... The file system is ext4..

I could just skip over it with an rsync exception, but I'm particularly interested in what could happen if it is deleted.

UPDATE: Both target and source are ext4

Regarding suggestions of it being a sparse file: If it is a sparse file, why would it show different sizes from one minute to the next? The file was certainly(?) not in use at the time. It is a ~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.sol file, of which there are many more such .sol files in that directory .. plus it did show an I/0 error on the first pass.

Also, according to man rsync, the suggested -S option is to handle sparse files efficiently, not properly, so that suggests to me that even though I wasn't using -S it should copy a sparse file accurately in either case: which it didn't, and even it if it is a sparse file, being 60.0 Peta Bytes seems surely(?) to be an error in the file system, somewhere... and that is my main concern: If there is a glytch in the file system, could deleting that file have repercussions on other files?

More specifically: as it wrote 13 GB of data, and climbing! when I cancelled it, could it also delete 13 GB - 60 PB of data when I delete it?

  • Does standard error and/or a log show the system call that caused the error? Error 3 is ESRCH (no such process), and a quick scan of usual suspect manpages wasn't very helpful. How non-deterministic is the size? Does it grow/shrink monotonically? Is it entirely random? What's the exact filename? Have you tried remounting the filesystem ro and fscking it? Sorry, lots of questions! – Alexios Jul 2 '12 at 20:17
  • I've only noticed the two sizes I mentioned above... at which point I actually deleted the file and then instantly thought "OMG what if....!!". I then checked a few random files on the system and things look to be okay, but that doesn't mean they are (I'll need to check the backup later). If it's a bad HD, it may have been read differently when I deleted it, so this question is now just academic; but in general I am primarily wondering if a corrupt file entry in the inode table (or whatever it is called) can cause data loss, even if the other files' inodes are still valid. (ext4) – Peter.O Jul 2 '12 at 21:20
  • Nothing's impossible! I've been running hundreds of ext[234] filesystems for a very long time (some under nasty power conditions), and I've never encountered this myself, but it could happen. Probably not as a result of a hardware disk issue. Still: run a suite of SMART tests if the disk/host adaptor supports them, and an fsck couldn't hurt either. If the file's gone, I suppose we'll never know. :) – Alexios Jul 2 '12 at 21:25
  • Thanks to everyone.. All seems well after deleting the file... and I've learnt more about sparse files.. (maybe I've even learnt to think twice, or more, before deleting whacky files :) – Peter.O Jul 3 '12 at 5:28
  • In case of such doubt, it is probably safest to umnount and run fsck(8). Just in case something got tied in a knot. – vonbrand Jan 23 '13 at 16:16

It looks like the source filesystem is damaged, typically either due to a kernel bug or to bad RAM (a damaged disk is more likely to result in unreadable files than corrupted data). At this point, all bets are off. However, if the corruption was very localized, it's only that one file's inode that's corrupted, and other files are undamaged, so you can safely delete the file. Note that there is no way to test this assumption.

My recommendation is to:

  1. Do a RAM test, or plug the disk into another machine.
  2. Ensure that you have backed up all your data.
  3. Check the health of the disk with SMART, if possible.
  4. Run fsck.
  5. If the disk is still good, go on using it.
  • Thanks Gilles... I haven't run a full check yet, but things look good, and the new system (Ubuntu 12.04; was 10.04) in now running on the target drive. – Peter.O Jul 3 '12 at 5:38

It's a sparse file. You should consider using -S, so that the file is handled as properly as possible.

  • Are you in my head, or am I in yours? I can't tell. :) It looks like we even edited our answers simultaneously. – Alexios Jul 2 '12 at 19:47
  • Please see my update re sparse files – Peter.O Jul 2 '12 at 19:58

This is most likely a sparse file. (if it isn't, start running now!) It doesn't actually occupy all this space, it has holes. Maybe one large hole.

Delete it from the rsync target side, then add the -S (sparse) option to rsync to make sure it recognises and deals with sparse files.

The target filesystem type should support sparse files too. (short version: ext[234] do, NTFS does, FAT doesn't)

  • Please see my update re sparse files – Peter.O Jul 2 '12 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.