Re: APFS root filesystem. All files' inode id have offset of 0x200000000
Re: APFS root filesystem. All files' inode id have offset of 0x200000000
- Subject: Re: APFS root filesystem. All files' inode id have offset of 0x200000000
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 22 Mar 2018 21:46:51 +0100
>
> So far I hadn't had much lack in scanning by this order, sparse filesystem
> makes the /.vol/<fsid>/<fileid> option inefficient.
> As for the searchfs option, I haven't seen in the man page any way to
> control the order of the files.
>
The order is arbitrary, as it walks over the btree nodes in the most
efficient manner, and that btree's order can change.
Still, if you want to keep the scan persistent between boots, a persistent
hashmap of the IDs is still the best option, IMO, as this lets you
determine which items you have already seen in a previous scan. Of course,
this means that you'll have to save the entire map regularly (and with
backups in place in case you crash during the save process) to protect
yourself against system crashes during your scan.
Be advised that searchfs is fairly fast if you only want to learn all used
fileID first, without actually learning the paths, yet. You can specify
that you want a large number of fileIDs returned in one go, so you can, for
instance, request chunks of a few 1000 IDs per call, then add them to your
hashmap, and save that map every few seconds if you're concerned about
system crashes (which I find rather unlikely to happen unless your program
runs in environments where this is more likely).
Once you have gathered all IDs (which may be in the range of a million,
easily), you can start requesting each ID's path and file attributes.
Hit me up privately if you need help with using searchfs.
Thomas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden