On Sat, Oct 22, 2011 at 12:27 PM, Robert Watzlavick
<rob...@watzlavick.com> wrote:
> What failure scenario could have caused this? The file was obviously
> initially good on the raidz because it got backed up to the USB drive and
> that matches the "good" version from the web.
I ran into a similar "failure" with a ZFS shared via SAMBA. The
data has ACLs on them to permit new data to be added, but nothing
modified or removed. When testing the configuration the end users had
no problems using Windows to copy data into the share. When they used
a specific tool to copy (and then verify via checksum) the data, it
was occasionally flagging a bad copy. Turns out that the tool was
actually copying _more_ data than was in the original and then going
back and removing the extra white space at the end of the file (the
files matched byte for byte up until the original ended and the copy
did not). The ZFS ACL was doing what the end user needed (no
modifications).
I reported the "problem" to the folks who wrote the tool and never
heard anything back. My end users have stopped using that tool for
copies, they still use it for verifications (and for that it is fine
as it does not try to change the data).
This was originally reported to me as a problem with ZFS, SAMBA,
or the ACLs I had set up. It is amazing how much _changing_ of data
goes on with no knowledge by the end users.
--
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
