3 ms·
> Reusing inodes is not that uncommon among filesystems I've been through that hell before and it completely sucks. BSD UFS will reuse an inode occasionally i
by gopalv 5y ago
> Reusing inodes is not that uncommon among filesystems
I've been through that hell before and it completely sucks.
BSD UFS will reuse an inode occasionally if you replace a file in a dir by delete + create (which makes sense, if you only cared about the efficiency of the dir structure).
But this meant that my caches which were keyed by device + inode + mtime, would fail to detect a file being updated.
As an obvious workaround, there was a 2 second delay into the system which seemed to fix things at first (apc.file_update_protection), but then it also stopped working for some people.
Because they were pushing data out to nodes through something like an rsync which also pushes an mtime update.
Anyway, the eventual workaround was to cache-break by ctime as well as mtime.
But it was hell to debug (months with 1 SEV1 ticket), because it would take a lot (a lot) to even triage the issue to the filesystem of why the file updates aren't going to the cache (& requests failing with API mismatches as the symptom).
Would not spring this on people without an explicit warning.
PS: Looks like ext4 does reuse them, whoa
- formerly_proven 5y agoI'm pretty sure most Unix-y file systems will reuse inodes with enough churn (eventually), because their design is generally one (or more) arrays for inodes with a free bitmap. NTFS should be very similar in behavior, though I'm not sure if the file index (~MFT index, basically the inode number) is actually used much, Windows itself tends to prefer object IDs as a persistent location-independent handle for files. Filesystem cache indexing should generally be done on the (name, type, inode, ctime) tuple (ideally include inode generation, but it's a fuss to get and doesn't make much difference in practice).