Inode ENOSPC due to recently_deleted()

Inode ENOSPC due to recently_deleted()

[Jan Kara]

Hello!

Recently, I've got a bug report about ext4 driver regressing compared to
the old ext2 driver. The problem is that the filesystem is small and they
fill the fs (use all inodes), then delete some files, and then want to use
the inodes for other files but recently_deleted() logic makes the freed
inodes unusable and thus inode allocation fails with ENOSPC.

AFAIU the logic implemented by recently_deleted() is more of a preference
than a hard rule and we should rather reuse recently deleted inodes than
return ENOSPC. Am I right?

Also I'd note that the detection whether the inode was written out in
recently_deleted() is very inaccurate - one of the problems is that if
several inodes in the same inode table block are deleted, then after
writing out that block we'll be able to reuse only one of these inodes
because by doing that, we certainly cache and dirty the inode block and
thus the recently_deleted() logic for other deleted inodes will start to
apply. But I think we can just live with that if we stop making
recently_deleted() a hard rule...

What do people think?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Inode ENOSPC due to recently_deleted()

[Theodore Y. Ts'o]

On Thu, Mar 05, 2020 at 06:14:31PM +0100, Jan Kara wrote:
> Hello!
> 
> Recently, I've got a bug report about ext4 driver regressing compared to
> the old ext2 driver. The problem is that the filesystem is small and they
> fill the fs (use all inodes), then delete some files, and then want to use
> the inodes for other files but recently_deleted() logic makes the freed
> inodes unusable and thus inode allocation fails with ENOSPC.
> 
> AFAIU the logic implemented by recently_deleted() is more of a preference
> than a hard rule and we should rather reuse recently deleted inodes than
> return ENOSPC. Am I right?
> 
> Also I'd note that the detection whether the inode was written out in
> recently_deleted() is very inaccurate - one of the problems is that if
> several inodes in the same inode table block are deleted, then after
> writing out that block we'll be able to reuse only one of these inodes
> because by doing that, we certainly cache and dirty the inode block and
> thus the recently_deleted() logic for other deleted inodes will start to
> apply. But I think we can just live with that if we stop making
> recently_deleted() a hard rule...

Yes, if we can't find any another inodes, rerying with
recently_deleted logic skipped makes sense.

						- Ted