Post by SnitPost by nospamPost by SnitPost by nospamPost by SnitPost by nospamPost by SnitBut, yes, HFS+ is outdated and it would be good to have it be replaced.
it's been updated over the years and works just fine.
I am FAR from an expert on file systems... but know it does not
handle many of the features of ZFS and the like such as block level
backups and checksums for integrity. Also recall something about it
not being able to handle requests as efficiently as NTFS, ext4, and
the like - but cannot go into detail or even be certain about that
without Googling.
hfs was never intended to be like zfs, which has its share of issues
too.
Fair enough... but if it is true that it needs to do far more reads and
seeks and the like than it should then that slows it down.
hfs doesn't need to do more reads and seeks than any other file system.
whoever said that is clueless.
Not at all an expert in this area and do not vouch for what I found but here
<http://rixstep.com/2/20031102,00.shtml>
-----
Every disk access on OS X goes to disk twice. At least twice.
That's right: accessing a file under OS X is slow. It has to be.
...
The implication of this 'caveat' is that a disk access in Mac OS X
requires at least two searches through the catalog file tree: the
first to determine the parent folder's CNID (this can be
recursive), and the second (or final) to find the file once the
CNID of the parent folder can be concatenated with the file name.
-----
Would love to see contrary information.
The double search in the catalog tree is true in the case where a file
needs to be located using its file ID. Where it goes wrong is that this
is not the usual method of finding a file.
Even when this method does need to be used, the catalog tree is probably
cached in memory, so it wouldn't involve two disk accesses.
Detail:
The catalog tree in HFS+ is a B*-tree sorted on a primary key of
(Catalog Node ID, filename). The CNID field is a 32-bit number which
uniquely identifies a file or folder within a volume.
There are two ways to locate a file within the catalog:
(a) Using the parent folder's ID, combined with the name of the file.
(b) Using the file's ID.
This is implemented as two entries in the catalog tree for each file.
The first entry is the "file record". It is located using the parent
folder ID and filename, so it allows the system to locate files by name.
The file record holds metadata (including the file ID, date/time stamps
and Finder info) and links to the file data. The sort order means that
files in the same folder have adjacent entries in the catalog tree,
allowing linear operations to be done in cases such as presenting a
directory listing.
The second entry is a "file thread record" which is located using the
file ID and points to the file record. These entries allow the system to
locate a file using just the file ID. The file thread record contains a
copy of the parent folder ID and filename.
Mac-native applications using standard APIs reference files using alias
records (which are also stored in alias files). Alias records contain
all three pieces of information: parent folder ID, filename, and file
ID. Given an alias record, the system tries to locate the file first
using the parent folder ID and filename (one catalog tree search). If
the file has been renamed or moved, then a second catalog tree search is
done using the file ID, which locates the file thread record pointing to
the new parent folder ID and filename, then a third catalog tree search
is used to get to the file record.
In OS X, many file search operations are done using a relative or
absolute pathname, with no ID numbers known. In this case, the system
parses the pathname, locates each folder in turn from the root (which
has a fixed parent folder ID) or current directory, until it gets the
folder ID of the target file's parent folder, then the final directory
lookup gets the file record. This is exactly how it works on other file
systems given a pathname.
The only case I can think of where the described scenario applies is if
an application was storing file IDs to locate its files. This might
happen in some POSIX applications which keep references to inode numbers
rather than pathnames, but it doesn't apply to the vast majority of
native Mac applications, nor to parts of the OS which understand that
alias records are a more efficient method to keep track of files.
--
David Empson
***@actrix.gen.nz