https://bugzilla.samba.org/show_bug.cgi?id=12819
Ben RUBSON changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
On Fri, 16 Jun 2017 12:34:40 +0200
Ben RUBSON via rsync wrote:
> > On 15 Jun 2017, at 19:29, Karl O. Pinc via rsync
> > wrote:
> > The problem is that the --server (and, especially,
> > --daemon) documentation has gone away. Or at least
> > left the man page. (v3.1.1, Debian 8, Jessie) Except
> On 15 Jun 2017, at 19:29, Karl O. Pinc via rsync
> wrote:
>
> On Thu, 15 Jun 2017 13:23:44 +
> just subscribed for rsync-qa from bugzilla via rsync
> wrote:
>
>> https://bugzilla.samba.org/show_bug.cgi?id=12819
>>
>> --- Comment #7 from Ben RUBSON ---
>
>> Note that my patch simply a
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #8 from Brian K. White ---
You tell me, what ABOUT a power failure between 2 zfs, or any other fs
operations?
This does not improve or solve any problem that the fs and all the other layers
aren't already handling. This is simply a mis
On Thu, 15 Jun 2017 13:23:44 +
just subscribed for rsync-qa from bugzilla via rsync
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=12819
>
> --- Comment #7 from Ben RUBSON ---
> Note that my patch simply adds a sync() just after recv_files(), so
> one sync() per connection, not per wr
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #7 from Ben RUBSON ---
And what about a power failure between 2 ZFS transaction groups ?
Note that my patch simply adds a sync() just after recv_files(), so one sync()
per connection, not per write operation.
Quite low workload actuall
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #6 from Brian K. White ---
Think of it this way, write() already makes a certain promise that it will not
return until it's done it's job, and it will not assert success when it can't.
Essentially the man page for any syscall is a contr
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #5 from Brian K. White ---
Any program could make this same "just to be safe" argument practically every
time they ever close-on-write for any reason. If they wrote anything, it was
always for some reason, and they want to know for sure
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #4 from Ben RUBSON ---
Yes Paul I thought about it but sync command may not be available if the server
(receiver) is chrooted (for example using patch proposed in #12817).
--
You are receiving this mail because:
You are the QA Contact
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #3 from Paul Slootman ---
How about just using a post-xfer command on the server side that does 'sync'?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid om
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #2 from Ben RUBSON ---
Thank you for your feedback Brian.
I don't have any problem.
I just want to be sure that when client (sender) has finished its transfer, its
data is on server's (receiver) disks, before it disconnects.
So that whe
https://bugzilla.samba.org/show_bug.cgi?id=12819
--- Comment #1 from Brian K. White ---
This seems wrong to me. If the OS is failing to manage write buffers and file
access between processes, you would have a lot bigger problems in every process
all through the system, and this wouldn't fix it.
12 matches
Mail list logo