smartupdate inflating target
 

OK, I've read through the troubleshooting section of the UG, and searched for, found, and read the threads about running out of space.

I'm having this problem now with our nightly backups. I understand the need for working space, but this problem is being exacerbated by the target volume ending up with more data on it than the source (after a successful smart update). I haven't done a fsdiff, but the source has 22GB free and the target has 5GB. I can understand them being off by a bit, but 15+ GB ??

If anything I would expect the reverse since I thought the copyscripts ignored some non-critical cache files, VM, etc.

I can do the erase and then copy, but I don't know for how long that will last because I don't know where this creep in storage is coming from...

-Preston

Did you look at the file it's failing on, Preston? If that's being written actively while we're backing it up, this can happen...

I had already resolved the out of space issue by deleting some larger files on the source and target to open up more working space, so now the 5GB remaining is enough for a successful smart update. So now the question is why the discrepancy after a successful smart update?

I'm going to runn a diff -qr to see if I can track it down.

Thanks,

-Preston

So, the file that was listed as failing in the log didn't provide any clue?

Nope - in this last case it was a single jpeg in an iphoto library, backup was afterhours, so it certainly wasn't some active videocapture file or something along those lines.

Previously the culprit was a rsnapshot log file that I had accidently left in verbose setting so was huge. The backup should have occurred after the rsnapshot was complete, so that log file should have been quiet.

Does SD use some hidden dir on the target to store working files? I couldn't find anything obvious with a quick look.

-Preston

Nope, no "working files" at all.