Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a laptop with a 512GB SSD in it. I use XFS as my / file system, mounted with noatime,discard,ikeep. The ikeep is because of some mailing list posting about how slow discard and TRIM was on XFS and suggested using ikeep to improve performance. However, in the Linux kernel docs it says:

When ikeep is specified, XFS does not delete empty inode clusters and keeps them around on disk. ikeep is the traditional XFS behaviour. When noikeep is specified, empty inode clusters are returned to the free space pool. The default is noikeep for non-DMAPI mounts, while ikeep is the default when DMAPI is in use.

Does this mean that no space would ever be freed if I use ikeep, thus making discard moot since no matter how many files I delete, the free space would not increase? That seems to be a preposterous idea for the "traditional XFS behavior".

What exactly does ikeep do?

share|improve this question
up vote 3 down vote accepted

ikeep does exactly what the documents say it does. I believe your confusion comes from not understanding what an inode is. An inode stores meta-data about the file. It is part of the filesystem structure and contains none of the data in the file. As the description of the patch which introduced the need for ikeep explains:

XFS dynamically allocates space for inodes as they are created, this is different from many other filesystems where inode space is statically allocated at mkfs time. While inode space is dynamically allocated, it is never freed - up until now that is.

This non-freeing of space tends to lead to fragmentation on filesystems where lots of files come and go. It can also lead to inodes and their parent directories being scattered around the disk more.

Most filesystems allocate all the inodes they will ever need when you "make the filesystem" a.k.a. "format the drive") and never delete them. XFS is different in that it makes them on demand.

Fragmentation and things being "scattered around the disk more" cause significant performance problems for traditional spinning-platter disks. However, on an SSD, those things are no problem at all. Conversely, deleting disk blocks is a significant performance problem on SSDs while being no problem for spinning-disks. So while the patch making it the default to delete empty inodes was a performance improvement for spinning-disks, it actually made performance worse on SSDs. Hence the recommendation to use ikeep on SSDs.

share|improve this answer
How exactly does this non-freeing of inodes cause fragmentation? – user54609 May 25 '13 at 21:51
It's actually not non-freeing of inodes that causes fragmentation, it's the dynamic allocation of inodes in parallel with allocation of blocks for file data that causes fragmentation. Rather, non-freeing of inodes locks in place any fragmentation caused in the first place. – Old Pro May 25 '13 at 21:55
Hmm. So the only reason XFS decided to do so was to squeeze a teeny bit more space and a teeny bit less mkfs time? O-o – user54609 May 25 '13 at 21:59
XFS is designed to support highly parallel operation and massive dynamically expanding file system sizes. Both are supported by dynamic allocation of inodes. – Old Pro May 25 '13 at 22:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .