[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #28 from Dave Gordon --- (In reply to Carson Gaspar from comment #27) Hmm? If you're referring to line 810 of io.c, which is the only write(2) call I can see in perform_io(), in the current HEAD it looks like this:

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #27 from Carson Gaspar --- (In reply to Dave Gordon from comment #23) Reading this, I took a look at the rsync sources, and, indeed, rsync has a bug. perform_io() does not correctly check the return code from

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #26 from Rui DeSousa --- (In reply to Ben RUBSON from comment #25) That is awesome. Thanks you for all of your efforts! -- You are receiving this mail because: You are the QA Contact for the bug. -- Please

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #24 from Ben RUBSON --- ZFS only shares between files with dedup on. So first rsync / diff succeeded, second gave same result as before : # rsync -a --inplace $tmpfs/f1 $f/f3 ; echo $? ; diff $tmpfs/f1 $f/f3 0

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #23 from Dave Gordon --- Looks like this ZFS problem could be a FreeBSD-specific issue; one of the commits mentioned in this FreeNAS bug report has the subject zfs_write: fix problem with writes appearing to succeed

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #22 from Dave Gordon --- (In reply to Ben RUBSON from comment #19) Just to be totally certain about what ZFS may or may not share between files, could you try this variant of your testcase: # zfs destroy $z # zfs

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #21 from Dave Gordon --- Created attachment 14019 --> https://bugzilla.samba.org/attachment.cgi?id=14019=edit Test patch to see whether fdatasync() or fsync() detects a write failure -- You are receiving this mail

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #20 from Dave Gordon --- So, looking like a ZFS issue but triggered in some way by the specific behaviour of rsync (e.g. writing a certain block size/pattern causes the quota error to be lost). The truss listing from a

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #19 from Ben RUBSON --- I managed to reproduce the issue on 11.0-RELEASE-p16. Below a simple test case, without compression, without deduplication. Note that issue is reproductible with quota, but not with

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #18 from Rui DeSousa --- I also wrote a little util as well; I get the correct error in write spot. [postgres@hades ~]$ cat 0001005E0017 | ./fwrite/fwrite arch/0001005E0017 fwrite:

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #17 from Rui DeSousa --- (In reply to Dave Gordon from comment #14) Here's the output you requested. ZFS would use the same block even if it's the same data as don't have dedup enabled. [postgres@hades ~]$ ls

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #16 from Rui DeSousa --- (In reply to Ben RUBSON from comment #15) I just set the quota property. NAME PROPERTY VALUE SOURCE hydra/home/postgres/arch quota 1G

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #15 from Ben RUBSON --- Rui just to be sure, which type of ZFS quota are you using ? quota ? refquota ? userquota ? -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #14 from Dave Gordon --- (In reply to Rui DeSousa from comment #6) So you now have an example which reliably produces a bad outcome (corrupted file)? With the combination of (a) insufficient space before copying, and

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #13 from Rui DeSousa --- (In reply to Rui DeSousa from comment #12) Running truss on the --sparse option does show the error being is returned during the write call. [postgres@hades ~]$ truss -f -o sparse.log

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #12 from Rui DeSousa --- (In reply to Dave Gordon from comment #10) The sparse option errors out :). [postgres@hades ~]$ rsync -av --sparse 0001005E0017 arch/0001005E0017 sending

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #11 from Rui DeSousa --- (In reply to Dave Gordon from comment #7) This is the result of hard link on the temp file where the rename failed. root@hades:~postgres/arch # ls -lh rsync.temp ; du -h rsync.temp

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #10 from Dave Gordon --- BTW, have you tried *either* --sparse *or* --preallocate (but not both together, please, as that will trigger bug 13320 - https://bugzilla.samba.org/show_bug.cgi?id=13320) Does you get the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #9 from Dave Gordon --- (In reply to Rui DeSousa from comment #6) In your example: $ rsync -av --inplace 0001005E0017 arch/0001005E0017 sending incremental file list 0001005E0017

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #8 from Ben RUBSON --- (In reply to Dave Gordon from comment #3) > ZFS probably notices the quota problem somewhere between (b) and (c), drops > the excess data, and returns EDQUOT to the close(2) call. (In

Re: [Bug 13317] rsync returns success when target filesystem is full

On Mon, Mar 5, 2018 at 3:09 PM, just subscribed for rsync-qa from bugzilla via rsync wrote: > https://bugzilla.samba.org/show_bug.cgi?id=13317 > > --- Comment #6 from Rui DeSousa --- > (In reply to Rui DeSousa from comment #5) > > It looks like no

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #7 from Dave Gordon --- (In reply to Rui DeSousa from comment #5) That was a run where the rename failed. Do you know whether the temporary file was truncated or corrupted in that scenario? [HINT: one can stop the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #6 from Rui DeSousa --- (In reply to Rui DeSousa from comment #5) It looks like no error is returned and result is a sparse file. I think a sync() would be required otherwise the file is truncated on close to

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #5 from Rui DeSousa --- (In reply to Dave Gordon from comment #4) Hi Dave, I'm not seeing any errors on the write calls. Would an fsync() be required to force the error? [postgres@hades ~]$ grep ERR

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #4 from Dave Gordon --- To see whether rsync is getting any errors reported by any system calls it makes, one could run it under strace(1) on Linux, or dtrace on Solaris. Presumably FreeBSD has at least one of these,

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #3 from Dave Gordon --- (In reply to Rui DeSousa from comment #2) Here's a snippet from Oracle's ZFS help ... https://docs.oracle.com/cd/E19253-01/819-5461/gitfx/index.html "Enforcement of user and group quotas might

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #2 from Rui DeSousa --- (In reply to Kevin Korb from comment #1) I saying that in some cases the rename does not fail; and in those cases it returns success despite there not being enough space to store the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #1 from Kevin Korb --- Are you saying that it is exiting with an exit code of 0 after outputting that error or that sometimes in the same condition it shows no error and exits code 0? Either way it would probably