Difference between vfsStruct.f_fsid and fstat.st_ino ?

Hello,

Anyone know of relevant documentation that captures the difference between vfsStruct.f_fsid and fstat.st_ino ?

sys/stat.h declares: ino_t st_ino; /* [XSI] File serial number */

AND

sys/statvfs.h declares: unsigned long f_fsid; /* Filesystem ID */

Based on some tests, it seems that the st_ino is the number/inode_number that the filesystem identifies the file-resource by ? I observed that this number gets a unique value when I copy a file even when the Finder/FS utilizes the Space-Saver feature of MacOS. This value is identical to the results returned by the command ls "-i" . When copying via Finder, I am seeing distinct st_ino values for source and destination files.

f_fsid seems to be identifying the File differently though, perhaps taking into account what Data/attributes objects the file resource points to ? I observed that this number gets an identical value when I copy a file even when the Finder/FS utilizes the Space-Saver feature of MacOS. So, the value of f_fsid seems to be copied over to the destination file record. Also, I could not find a way to display f_fsid via the ls command.

On a related note, Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented ?

Thanks, Vikram.S.Warraich

Anyone know of relevant documentation that captures the difference between vfsStruct.f_fsid and fstat.st_ino?

There things aren’t related at all. st_ino is the inode number, that is, a unique identifier for the file. In contrast, f_fsid is a unique identifier for the file system, that is, the volume on which the file resides. The getattrlist man page makes this clear:

  • ATTR_CMN_FSIDAn fsid_t structure containing the file system identifier for the volume on which the file system object resides. Equivalent to the f_fsid field of the statfs structure returned by statfs.

  • ATTR_CMN_FILEIDA u_int64_t that uniquely identifies the file system object within its mounted volume. Equivalent to st_ino field of the stat structure returned by stat.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks @eskimo.

Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented ?

Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented?

I don’t understand this question. You’re using a bunch of words that don’t map to any technology that I recognise. Can you post a link to the user-level documentation for the feature you’re interested in?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Greetings,

It turns out that feature-info I was looking for is about an APFS feature called Copy-On-Write-Clones . I was able to view documentation on it so I am good for now.

For Finder copy-operations, with destination being the same volume, APFS seems to be creating the new file with different meta-data but the file shares the same data-content as the original. During my tests, I found that copying a 1GB file on the same volume via Finder did not decrease the available space on the Volume by 1GB. What was cool was that if I appended to the new File, then the disk-available-space gets decreased by only the bytes that were appened to the new File. So, the Sharing of data-content/blocks continues even post the edit. I ran some more tests with Finder and /bin/cp command. 1). As expected, the same Finder copy operation on HFS+ volumes has a different behavior than Finder copies on APFS. 2). However when comparing Finder-based-copy operation with cp-command copy operation on MacOS-APFS, the behavior strangely differs when it comes to CopyOnWriteClones. Not sure why, but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig; Finder based copies on the other hand are exibiting the space-saving behavior.

Thanks,

Vikram.S.Warraich.

Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy. cp -c : copy files using clonefile(2)

Also, The f_fsid related observations/content in my first comment on this post is not correct. Thanks @eskimo for correcting me regarding that st_ino and f_fsid are not related.

but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig

Yes.

cp is a BSD-level tool, and BSD traditionally doesn’t have a ‘copy file’ API. Thus, cp opens both files and copies the data chunk-by-chunk, which means it won’t benefit from APFS’s CoW support.

Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy. cp -c

Yep. This isn’t the default because folks might depend on the subtle semantics of cp.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Difference between vfsStruct.f_fsid and fstat.st_ino ?
 
 
Q