On Wed, 2004-12-01 at 01:04 -0600, John Van Essen wrote: > On Tue, 30 Nov 2004, Dan Stromberg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
signature.asc
Description: This is a digitally signed message part
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
