rsync creating 0-length files?

[Dan Stromberg]

On Wed, 2004-12-01 at 01:04 -0600, John Van Essen wrote:
> On Tue, 30 Nov 2004, Dan Stromberg <strombrg at dcs.nac.uci.edu> wrote:
> > 
> > We were doing a roughly 1 terabyte transfer, and upon running a python
> > script to verify the integrity of the transfer, we discovered a small
> > number of files that were 0 length, that shouldn't have been, all in the
> > same user's account.
> 
> In the same user's account, eh?
> 

Yup.

> On Tue, 30 Nov 2004, Wayne Davison <wayned at samba.org> wrote:
> > On Tue, Nov 30, 2004, Dan Stromberg wrote:
> >> If a close were to fail, wouldn't that normally mean that you just
> >> wouldn't get the last block sync'd out to disk, rather than an entire
> >> multi-K or multi-M file would be 0 length?
> > 
> > If the disk is full (i.e. out of blocks, but not inodes) or if the user
> > is over quota, you'd typically get a 0-length file (but the program may
> > not get any errors until the close call, when the data gets flushed out
> > to disk).
> 
> Speaking from rsync experience, if a *nix partition becomes completely
> full, you do get an immediate NO SPACE error on a write() and rsync
> reports it.

Good to know.

> But since all the problems were associated with a particular user,
> perhaps it is a quota issue, and write() calls in that case might
> not return an error (which would be unfortunate...).
> 
> Dan - can you check that user's quota?

The destination filesystem type does not support quotas at this time.
We're writing to a "Lustre" distributed filesystem.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20041201/feba71e1/attachment.bin