From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
t-sato@yk.jp.nec.com, m-hamaguchi@ys.jp.nec.com,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH 3/4] Do not allow umounting of frozen filesystems
Date: Wed, 23 Sep 2009 01:41:09 +0900 [thread overview]
Message-ID: <4AB8FE25.90806@oss.ntt.co.jp> (raw)
In-Reply-To: <20090922110737.GL5858@ZenIV.linux.org.uk>
Al Viro さんは書きました:
> On Thu, Aug 27, 2009 at 11:06:07PM +0900, Fernando Luis V?zquez Cao wrote:
>
>> Instead of making umount users wait until the filesystem is
>> unfreezed return EBUSY, which is very convenient in HA
>> configurations.
>>
>> This could have been implemented at a lower level but it would
>> require considerable plumbing in functions such as release_mounts
>> which do not return errors.
>>
>
>
>> + if (sb->s_bdev != NULL) {
>> + mutex_lock(&sb->s_bdev->bd_fsfreeze_mutex);
>> + if (sb->s_frozen != SB_UNFROZEN) {
>> + mutex_unlock(&sb->s_bdev->bd_fsfreeze_mutex);
>> + return -EBUSY;
>> + }
>> + }
>>
>
> NAK. First of all, it _partially_ breaks umount -l for no good reason.
> If the first fs on the mountpoint is frozen, we fail; if it's deeper
> we succeed just fine (and delay actual fs shutdown until the thaw).
>
> As far as I can see, the real problem is that fsthaw ioctl has braindead
> API; it takes some opened file on fs in question. Why not do a bdev
> ioctl instead? Then we could let umount go ahead just fine, leaving
> fs frozen (and not shut down until it thaws). And whoever does thaw
> (via bdev ioctl) will automatically trigger the actual fs shutdown.
> Just with Christoph's pair of patches...
>
I basically agree with you. The current API creates a lot of locking
issues that could be tackled
more cleanly with the bdev ioctls you suggest.
> IOW, I'd rather add two new ioctls (check if frozen/thaw), both by
> bdev. On top of the first two patches in this set.
>
I am happy to see you would welcome a check ioctl.
If there is consensus on the bdev ioctl approach I could send patches.
Thanks,
Fernando
next prev parent reply other threads:[~2009-09-22 16:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 5:00 [RFC, PATCH] filesystem freeze: fix sys_umount induced perpetual freeze Fernando Luis Vázquez Cao
2009-08-26 17:38 ` Christoph Hellwig
2009-08-27 10:11 ` Fernando Luis Vázquez Cao
2009-08-27 11:54 ` Christoph Hellwig
2009-08-27 12:16 ` Fernando Luis Vázquez Cao
2009-08-27 14:05 ` [PATCH 1/4] freeze_bdev: kill bd_mount_sem Fernando Luis Vázquez Cao
2009-08-27 14:06 ` [PATCH 2/4] freeze_bdev: grab active reference to frozen superblocks Fernando Luis Vázquez Cao
2009-08-27 14:06 ` [PATCH 3/4] Do not allow umounting of frozen filesystems Fernando Luis Vázquez Cao
2009-09-22 11:07 ` Al Viro
2009-09-22 15:57 ` Eric Sandeen
2009-09-22 16:46 ` Fernando Luis Vazquez Cao
2009-09-22 16:41 ` Fernando Luis Vazquez Cao [this message]
2009-08-27 14:06 ` [PATCH 4/4] filesystem freeze: add ISFROZEN ioctl Fernando Luis Vázquez Cao
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=4AB8FE25.90806@oss.ntt.co.jp \
--to=fernando@oss.ntt.co.jp \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=m-hamaguchi@ys.jp.nec.com \
--cc=sandeen@redhat.com \
--cc=t-sato@yk.jp.nec.com \
--cc=viro@ZenIV.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox