4 ms·
Also a longer critique by John Siracusa here: http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/#hfs-problems http://arstechnica.com/apple/2011/07/mac-os-x-
by terminus 12y ago
Also a longer critique by John Siracusa here: http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/#hfs-problems http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/#hfs-p...
I wonder how this ties in with the whole Apple philosophy of "Design is how it works."
Clearly the innards look nothing like the facade.
- yuhong 12y agoWonder why the "HFS+ Private Data" hack was chosen when Rhapsody existed even back in 1997.
- Someone1234 12y ago> File system metadata structures in HFS+ have global locks. Only one process can update the file system at a time. Holy heck! How does that work in practice? Do operations get queued and then a single kernel process who can take the lock do the atomic updates? I have to imagine that is going to cause a bottleneck however, as all non-read operations need to update the metadata (e.g. timestamp, maybe size if it is stored). That all being said I haven't noticed OS X being particularly slower to do things than e.g. Windows. So if that is the case they're hiding it well.
- mindajar 12y agoHFS+ is an oddball filesystem among FSes that anyone actually uses. Since the earliest days of the Mac, it's been able to e.g. track file identity even as a file is moved around, and the metadata to support this lives in a volume-wide tree called the Catalog File. So, there's your global lock. (Add an SSD as necessary for better performance.) OS X already has some pretty high-level file and metadata APIs not found on other systems, so maybe Apple's future plans don't look like a traditional Unix file system at all. They've already demonstrated they know how to make a very weird, non-Unix filesystem look like one. ;)