The xfs filesystem can exceed the current lockdep MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes, they all get locked in xfs_ifree_cluster(). The normal cluster size is 8192 bytes,
As 40 will still not be enough for people with larger block sizes, this does not seems like a solid solution. Could XFS possibly batch in smaller (fixed sized) chunks, or does that have significant d
The problem is not filesystem block size, it's the xfs inode cluster buffer size / the size of the inodes that determines the lock depth. the common case is 8k/256 = 32 inodes in a buffer, and they a
Since they are all trylocks it seems to suggest there is no hard _need_ to lock a whole inode cluster at once, and could iterate through it with less inodes locked. Granted I have absolutely no under
Right, but as I understand it, the cluster size *minimum* is the block size; that's why I made reference to block size - 16k blocks would have 64 inodes per cluster, minimum, potentially all locked i
That's kind of misleading. They are trylocks to prevent deadlocks with other threads that may be cleaning up a given inode or the inodes may already be locked for writeback and so locking them a seco
I think this started because jeffpc couldn't boot without XFS busting lockdep :-) No, alas, we cannot handle semaphores in lockdep. Semaphores don't have a strict owner, hence we cannot track them. T
The xfs filesystem can exceed the current lockdep MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes, they all get locked in xfs_ifree_cluster(). The normal cluster size is 8192 bytes,
As 40 will still not be enough for people with larger block sizes, this does not seems like a solid solution. Could XFS possibly batch in smaller (fixed sized) chunks, or does that have significant d
The problem is not filesystem block size, it's the xfs inode cluster buffer size / the size of the inodes that determines the lock depth. the common case is 8k/256 = 32 inodes in a buffer, and they a
Since they are all trylocks it seems to suggest there is no hard _need_ to lock a whole inode cluster at once, and could iterate through it with less inodes locked. Granted I have absolutely no under
Right, but as I understand it, the cluster size *minimum* is the block size; that's why I made reference to block size - 16k blocks would have 64 inodes per cluster, minimum, potentially all locked i
That's kind of misleading. They are trylocks to prevent deadlocks with other threads that may be cleaning up a given inode or the inodes may already be locked for writeback and so locking them a seco
I think this started because jeffpc couldn't boot without XFS busting lockdep :-) No, alas, we cannot handle semaphores in lockdep. Semaphores don't have a strict owner, hence we cannot track them. T