Eric,
Thanks for the info, that can explain the offset since I previously
upgraded the OS from Sierra which uses HFS+ for its root filesystem.
The reason that brought me looking into the fileid values, is some file
scanner design I'm currently working on that instead of iterating the files
according to their directory structure (i.e. BFS), I iterate according to
ascending file-id attribute, where I always assumed that the file-id starts
from zero.
Using this scanning order, I can halt my scanning and regain to it
according to the last scanned file-id (assuming that I can ignore newly
created files that got file-id value lower than this last scanned value).
I'd be happy if you could tell me what is the file-id allocation policy in
APFS or HFS+ in the following aspects
1. Is there any way to extract the current file-id range (minimum to
maximum fileid).
2. I've noticed that there are some gaps in file-id list. meaning that some
ids aren't connected to files. How can this happen (I assume it's due to
deleted files), and when creating new file, does it get file-id from the
lowest available value or the next file-id after the current maximum value.
3. I'd like to use an array that each index represent a file-id. Can I
assume that the file-ids aren't sparse (meaning that the gaps of unused id
values are small) so that I won't waste too much memory ?
4. Do you recommend other, more efficient way to iterate through the files
in order to ascending file-id, other than through the /.vol/ drive ?
Thanks a lot for your help.
Irad,
On Wed, Mar 21, 2018 at 6:53 PM, Eric Tamura <etam...@apple.com> wrote:
> Irad,
>
> This is because your volume went through the HFS -> APFS converter. As a
> side effect of some on-disk APFS format differences from HFS, we need to
> make sure we can differentiate large EAs and resource from data forks. So
> the large EAs/resource forks in APFS retain the original HFS inode number,
> plus 0x10000000, since that number can’t possibly be in use in HFS (maximum
> of 32 bits for fileIDs). This means that all new APFS objects (files,
> directories, EAs, etc) start at 0x20000000. This does mean that we burned
> the range of inode numbers from 0x100000000 -> 0x1ffff ffff… however with
> 64 bits of inodes, this was determined to be an acceptable trade-off.
>
> Newly formatted APFS volumes are not subject to this behavior.
>
> Eric
>
>
>
> On Mar 21, 2018, at 8:35 AM, Irad K <iradizat...@gmail.com> wrote:
>
> Hi,
>
> I'm trying to figure out why my files are all allocated with huge fileid.
>
> Setup:
> - root filesystem is formatted to APFS
> - macOS version High Sierra.
>
>
> For some reason, all my files are allocated with fileid that is added to
> offset of `0x200000000`
>
> For example, create new file `/tmp/1` and getting its attributes will
> produce
>
> -> *stat /tmp/1*
>
> 16777220 *8595046795 <(859)%20504-6795>* -rw-r--r-- 2 demouser wheel
> 0 7237 "Mar 21 16:42:57 2018" "Mar 21 16:42:36 2018" "Mar 21 16:42:36 2018"
> "Mar 21 14:29:12 2018" 4194304 16 0 /tmp/1
>
> (8595046795 <(859)%20504-6795> is 0x200000000 in hex)
>
>
> Furthermore, if I search for valid inode ABOVE this offset in /.vol/ mount
> drive, I find plenty, but below there are none.
>
> for x in {1..10000}; do stat /.vol/${filesystemid}/$((0x200000000-x)) >>
> /dev/null 2&>1 && echo "fileid $x + 0x200000000 exit"; done
> fileid 115 + 0x200000000 exit
> fileid 116 + 0x200000000 exit
> fileid 139 + 0x200000000 exit
> fileid 140 + 0x200000000 exit
> fileid 141 + 0x200000000 exit
> fileid 142 + 0x200000000 exit
> fileid 144 + 0x200000000 exit
> fileid 145 + 0x200000000 exit
> fileid 146 + 0x200000000 exit
> fileid 147 + 0x200000000 exit
>
> fileid 149 + 0x200000000 exit
>
>
> Is there any rigorous API to retrieve this offset ? where can I find it ?
> looked for in APFS header but didn't find an appropriate field.
>
> thanks
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/filesystem-dev/etamura%40apple.com
>
> This email sent to etam...@apple.com
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
