From: Dmitry Monakhov <dmonakhov@openvz.org>
To: "linux-ext4\@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 3/3] ext4: Handle non empty on-disk orphan link
Date: Fri, 26 Feb 2010 01:55:45 +0300 [thread overview]
Message-ID: <87r5o9orgu.fsf@openvz.org> (raw)
In-Reply-To: <1267132807-5882-3-git-send-email-dmonakhov@openvz.org> (Dmitry Monakhov's message of "Fri, 26 Feb 2010 00:20:07 +0300")
Dmitry Monakhov <dmonakhov@openvz.org> writes:
> In case of truncate errors we explicitly remove inode from in-core
> orphan list via orphan_del(NULL, inode) without on-disk list
> modification.
> But later same inode may be inserted in the orphan list again which
> result in on-disk link corruption.
There is another "100% reliable" way to solve the issue.
In case of truncate error instead of cleaning in-core inode's list
we may just reinsert it in to another sb->s_orphan_error list.
In this case orphan_add() will works without changes because
!list_empty() check will works as expected. And if later it is
also possible to call orphan_del().
Later we even may try to replay this s_orphan_error list for
example before umount/remount
But this solution has major disadvantage. We can have to pin
inode in to memory to prevent inode pruning.
This is not best choice because usually truncate failed
because of ENOMEM.
That's why i use this not absolutely reliable but simple approach.
> If inode i_dtime contains valid
> value let skip on-disk list modification.
>
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
> ---
> fs/ext4/namei.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 17a17e1..19ca9bf 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -2020,6 +2020,13 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
> err = ext4_reserve_inode_write(handle, inode, &iloc);
> if (err)
> goto out_unlock;
> + /*
> + * Due to previous errors inode may be already a part of on-disk
> + * orphan list. If so skipp on-disk list modification.
> + */
> + if (NEXT_ORPHAN(inode) && NEXT_ORPHAN(inode) <=
> + (le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count)))
> + goto mem_insert;
>
> /* Insert this inode at the head of the on-disk orphan list... */
> NEXT_ORPHAN(inode) = le32_to_cpu(EXT4_SB(sb)->s_es->s_last_orphan);
> @@ -2037,6 +2044,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
> *
> * This is safe: on error we're going to ignore the orphan list
> * anyway on the next recovery. */
> +mem_insert:
> if (!err)
> list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);
next prev parent reply other threads:[~2010-02-25 22:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 21:20 [PATCH 1/3] ext4: fix error handling in migrate Dmitry Monakhov
2010-02-25 21:20 ` [PATCH 2/3] ext4: explicitly remove inode from orphan list after failed direct io Dmitry Monakhov
2010-02-25 21:20 ` [PATCH 3/3] ext4: Handle non empty on-disk orphan link Dmitry Monakhov
2010-02-25 22:55 ` Dmitry Monakhov [this message]
2010-03-02 4:33 ` tytso
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=87r5o9orgu.fsf@openvz.org \
--to=dmonakhov@openvz.org \
--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.