#1329 closed defect (fixed)

Improve visibility/debuggability when mangling filesystem permissions

Reported by: gcooper Owned by: jhixson
Priority: major Milestone:
Component: Backend Version: 8.0.1-RELEASE
Keywords: Cc:

Description

I have gotten a lot of complaints from users/customers about the fact that setting recursive permissions takes a long time, and without sufficient feedback / visibility into what the heck is actually going on, I totally understand (especially because chown+chmod+setfacl is done in such a brute force way and it takes hours on larger storage arrays).

Instead of brute forcing the solution, like what was suggested earlier in an internal discussion, statfs(2) provides this info in the struct statfs structure:

     int
     statfs(const char *path, struct statfs *buf);

...

     struct statfs {
...

     uint64_t f_files;               /* total file nodes in filesystem */
     ^^^^^^^^^^^^^^^^^^^^^^^^^ HERE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     int64_t  f_ffree;               /* free nodes avail to non-superuser */
     ^^^^^^^^^^^^^^^^^^^^^^^^^ AND HERE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

     };

So using os.statvfs will give us our desired result:

$ sudo sh -c 'find -x /scratch/freenas | wc -l'
  129986
$ python -c 'import os; res = os.statvfs("/scratch/freenas"); print res.f_files - res.f_ffree'
125161

Not exactly the same -- but in a proper, rough ballpark (which is a lot better than the current implementation provides).

Please implement the feature in a manner similar to what the firmware upgrade mechanism uses (because that's slick).

Also, providing a "verbose mode" for what file is being touched would be really nice...

Change History (2)

comment:1 Changed 15 months ago by jhixson

  • Owner set to jhixson
  • Status changed from new to assigned

comment:2 Changed 14 months ago by jhixson

  • Resolution set to fixed
  • Status changed from assigned to closed

This is pretty much a duplicate of #1330, closing this out too.

Note: See TracTickets for help on using tickets.