On 5/15/19 11:47 AM, Jorge Guerra wrote: > On Wed, May 15, 2019 at 9:24 AM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >>>> For example, xfs_db is not the right tool for probing online, active >>>> filesystems. It is not coherent with the active kernel filesystem, >>>> and is quite capable of walking off into la-la land as a result of >>>> mis-parsing the inconsistent filesystem that is on disk underneath >>>> active mounted filesystems. This does not make for a robust, usable >>>> tool, let alone one that can make use of things like rmap for >>>> querying usage and ownership information really quickly. >>> >>> I see your point, that the FS is constantly changing and that we might >>> see an inconsistent view. But if we are generating bucketed >>> histograms we are anyways approximating the stats. >> >> I think that Dave's "inconsistency" concern is literal - if the on-disk >> metadata is not consistent, you may wander into what looks like corruption >> if you try to traverse every inode while mounted. >> >> It's pretty much never valid for userspace to try to traverse or read >> the filesystem while mounted. > > Sure, I understand this point. Then can we: > > 1) Abort scan if the we detect "corrupt" metadata, the user would then > either restart the scan or decide not to. > 2) Have a mechanism which detects if the FS changed will scan was in > progress and tell the user the results might be stale? none of that should be shoehorned into xfs_db, tbh. It's fine to use it while unmounted. If you want to gather these stats on a mounted filesystem, xfs_db is the wrong tool for the job. It's an offline inspection tool. The fact that "-r" exists is because developers may need it, but normal admin-facing tools should not be designed around it. >> >>>> To solve this problem, we now have the xfs_spaceman tool and the >>>> GETFSMAP ioctl for running usage queries on mounted filesystems. >>>> That avoids all the coherency and crash problems, and for rmap >>>> enabled filesystems it does not require scanning the entire >>>> filesystem to work out this information (i.e. it can all be derived >>>> from the contents of the rmap tree). >>>> >>>> So I'd much prefer that new online filesystem queries go into >>>> xfs-spaceman and use GETFSMAP so they can be accelerated on rmap >>>> configured filesystems rather than hoping xfs_db will parse the >>>> entire mounted filesystem correctly while it is being actively >>>> changed... >>> >>> Good to know, I wasn't aware of this tool. However I seems like I >>> don't have that ioctl in my systems yet :( >> >> It was added in 2017, in kernel-4.12 I believe. >> What kernel did you test? > > Yeap, that's it we tested in 4.11. Catch up! *grin* -Eric
