On Sun, Jul 31, 2016 at 09:12:23AM +0300, Amir Goldstein wrote: > On Sun, Jul 31, 2016 at 3:34 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > i.e. it's all the same coherency issues that we have with multiple > > NFS clients modifying the same file concurrently. They don't know > > what each other are doing, and so modifications are going to get > > lost or be overwritten incorrectly.... > > All the disclaimers above are very important for the administrator to know. Administrator != developer. These are things a filesystem tool developer would need to know. They are far, far outside the realm of what a system administrator needs to know or wants to care about. > But I believe that the answer to Ryan's original question is: > Yes, there is a way of interacting at the file system level to > facilitate a change > of UID's on files rather than having to just chown recursively down > the file system. It's not supported - you'll get to keep all the broken bits to yourself if you do something like this. You get to handle all the undocumented wacky corner cases yourself, like unlinked inodes, inodes that the scan misses because they were created in a region already scanned before the bulkstat completes, handling partial completion failures, invalidation of all your backups because they can't obviously detect that changes have been made, etc. > I'm not sure how much faster it is going to be and whether anyone > would want to invest time in writing this bulkchown tool, but it > is definitely going to reduce Ryan's system downtime. Is it, though? You say it like it's an unconditional win, but that's nt necessarily true. i.e. if directory travesal isn't the limiting factor (e.g. single threaded chown process is the limiting factor), then simply running concurrent chowns is will be the fastest and simplest method to scale this out. > Please correct me if I am wrong. Bulkstat is not a general purpose API. You can use it if you want to, but if you don't understand /exactly/ what it is providing, then the application that uses it wll be buggy and quite possibly dangerous to the user's data and/or filesystem structure. You're welcome to play russian roulette with your own filesystems, but please don't advocate that others should do play along with you... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
