On Jul 27, 2010, at 3:09 PM, Chris Murphy wrote: > > > On Jul 27, 2010, at 12:52 PM, Dan Shoop wrote: > >> >> On Jul 27, 2010, at 2:49 PM, Chris Murphy wrote: >> >>> On Jul 27, 2010, at 12:26 PM, Dan Shoop wrote: >>> >>>> >>>> On Jul 27, 2010, at 12:13 PM, Chris Murphy wrote: >>>> >>>>> >>>>> On Jul 27, 2010, at 9:32 AM, Dan Shoop wrote: >>>>>> >>>>>> The latter is not a supported operation. Yes, I know that sounds crazy >>>>>> but that's not a workflow Adobe approves of with their products Instead >>>>>> save locally, then copy. Directly saving files in Adobe products to >>>>>> fileshares has never been supported by Adobe. >>>>> >>>>> Understood but it has worked flawlessly from InDesign for a year with >>>>> POSIX permissions. Upon changing to ACLs, we get a permissions error from >>>>> InDesign. Today we removed the ACLs, and went back to conventional >>>>> permissions and now InDesign can write directly into these drop folders. >>>> >>>> Which only indicates that you did not properly capture the required set of >>>> ACEs. Anything you can do with ownerships and permissions you can achieve >>>> better with ACLs. >>> >>> Seems like a reasonable explanation. >>> >>> Admins on the other end are telling me that during the test phase the ACLs >>> were working correctly for all users and all drop folders. And then >>> inexplicably a week into deployment users started getting the permissions >>> error from InDesign. >> >> So something may have changed. > > *shrug* Not intentionally! i.e. at least no one is fessing up to having > modified the shares' ACLs between the time it was working and the time it > wasn't working; and also the ACLs as reported by ls -le are the same when it > was working and when it wasn't working. But heck with marginal drives it may > not be the ACLs that are corrupting, but something else related to either the > interpretation of them.
This is the problem with silent data corruption. It can occur anyplace. However data corruption of filesystem metadata is about the only corruption that is repairable. >>> And this approximately coincides with the XServe announcing a SMART failure >>> prediction for one of the mirrored drives. So for all I know, iffy drives >>> are corrupting themselves and it's just coincidentally making ACLs look >>> like the problem. >> >> >> Entirely possible. Google for "Silent Data Corruption". > > Wow. That's kinda shocking. I mean, it shouldn't be, but it's almost like > we're f'd with a basic backup plan because the odds of having simultaneous > corruption of a critical file over the course of time on two separate drives > is actually not insignificant. Which is why it's such a problem. It's why there's ZFS. >> >> And this isn't a RAID5, is it? If so, you're in for problems. > > It is RAID 1. So, yes. Then no, you have significantly more protection against corruption, but a RAID1 /pair/ has no idea which member has the non-corrupt data. It can just protect against a block being unreadable. > It's a relatively low priority server, in that it's not accumulating critical > data. We can blow it away, rebuild it, and restore the print queues very > quickly and be back up and running - even if we had to change platforms since > it's a 3-platform RIP. However, the lack of error detection means the > software RAID 1 likely took corruption as valid changes and propagated that > to the other drive. It doesn't work that way. -d ------------------------------------------------------------------------ Dan Shoop Computer Scientist [email protected] GoogleVoice: 1-646-402-5293 aim: iWiring twitter: @colonelmode _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
