From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Inode ENOSPC due to recently_deleted()
Date: Thu, 5 Mar 2020 14:37:12 -0500 [thread overview]
Message-ID: <20200305193712.GD4747@mit.edu> (raw)
In-Reply-To: <20200305171431.GM21048@quack2.suse.cz>
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
prev parent reply other threads:[~2020-03-05 19:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 17:14 Inode ENOSPC due to recently_deleted() Jan Kara
2020-03-05 19:37 ` Theodore Y. Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200305193712.GD4747@mit.edu \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.