From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@ZenIV.linux.org.uk>,
dchinner@redhat.com, LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, Alex Elder <elder@kernel.org>,
Anton Altaparmakov <anton@tuxera.com>, Ben Myers <bpm@sgi.com>,
Chris Mason <chris.mason@oracle.com>,
cluster-devel@redhat.com, "David S. Miller" <davem@davemloft.net>,
fuse-devel@lists.sourceforge.net,
"J. Bruce Fields" <bfields@fieldses.org>,
Joel Becker <jlbec@evilplan.org>,
KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net,
Mark Fasheh <mfasheh@suse.com>,
Miklos Szeredi <miklos@szeredi.hu>,
ocfs2-devel@oss.oracle.com,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Steven Whitehouse <swhiteho@redhat.com>,
Theodore Ts'o <tytso@mit.edu>,
xfs@os
Subject: Re: [PATCH 00/19 v5] Fix filesystem freezing deadlocks
Date: Tue, 17 Apr 2012 11:32:46 +0200 [thread overview]
Message-ID: <20120417093246.GD7198@quack.suse.cz> (raw)
In-Reply-To: <C9A0E2F0-ED57-40D6-9F75-5D72D45D21F0@dilger.ca>
On Mon 16-04-12 15:02:50, Andreas Dilger wrote:
> On 2012-04-16, at 9:13 AM, Jan Kara wrote:
> > Another potential contention point might be patch 19. In that patch
> > we make freeze_super() refuse to freeze the filesystem when there
> > are open but unlinked files which may be impractical in some cases.
> > The main reason for this is the problem with handling of file deletion
> > from fput() called with mmap_sem held (e.g. from munmap(2)), and
> > then there's the fact that we cannot really force such filesystem
> > into a consistent state... But if people think that freezing with
> > open but unlinked files should happen, then I have some possible
> > solutions in mind (maybe as a separate patchset since this is
> > large enough).
>
> Looking at a desktop system, I think it is very typical that there
> are open-unlinked files present, so I don't know if this is really
> an acceptable solution. It isn't clear from your comments whether
> this is a blanket refusal for all open-unlinked files, or only in
> some particular cases...
Thanks for looking at this. It is currently a blanket refusal. And I
agree it's problematic. There are two problems with open but unlinked
files.
One is that some old filesystems cannot get in a consistent state in
presence of open but unlinked files but for filesystems we really care
about - xfs, ext4, ext3, btrfs, or even ocfs2, gfs2 - that is not a real
issue (these filesystems will delete those inodes on next mount read-write).
The other problem is with what should happen when you put last inode
reference on a frozen filesystem. Two possibilities I see are:
a) block the iput() call - that is inconvenient because it can be
called in various contexts. I think we could possibly use the same level of
freeze protection as for page fault (this has changed since I originally
thought about this and that would make things simpler) but I'm not
completely sure.
b) let the iput finish but filesystem will keep inode on its orphan list
(or it's equivalent) and the inode will be deleted after the filesystem is
thawed. The advantage of this is we don't have to block iput(), the
disadvantage is we have to have filesystem support and not all filesystems
can do this.
Any thoughts?
Honza
>
> lsof | grep deleted
> nautilus 25393 adilger 19r REG 253,0 340 253954 /home/adilger/.local/share/gvfs-metadata/home (deleted)
> nautilus 25393 adilger 20r REG 253,0 32768 253964 /home/adilger/.local/share/gvfs-metadata/home-f332a8f3.log (deleted)
> gnome-ter 25623 adilger 22u REG 0,18 17841 2717846 /tmp/vtePIRJCW (deleted)
> gnome-ter 25623 adilger 23u REG 0,18 5568 2717847 /tmp/vteDCSJCW (deleted)
> gnome-ter 25623 adilger 29u REG 0,18 480 2728484 /tmp/vte6C1TCW (deleted)
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2012-04-17 9:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 16:13 [PATCH 00/19 v5] Fix filesystem freezing deadlocks Jan Kara
2012-04-16 16:13 ` [PATCH 17/27] ext4: Convert to new freezing mechanism Jan Kara
[not found] ` <1334592845-22862-1-git-send-email-jack-AlSwsSmVLrQ@public.gmane.org>
2012-04-16 16:16 ` [PATCH 00/19 v5] Fix filesystem freezing deadlocks Jan Kara
2012-04-16 22:02 ` Andreas Dilger
2012-04-17 0:43 ` Dave Chinner
2012-04-17 5:10 ` Andreas Dilger
2012-04-18 0:46 ` Chris Samuel
2012-04-17 9:32 ` Jan Kara [this message]
[not found] ` <20120417093246.GD7198-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
2012-04-17 19:34 ` Joel Becker
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=20120417093246.GD7198@quack.suse.cz \
--to=jack@suse.cz \
--cc=adilger@whamcloud.com \
--cc=anton@tuxera.com \
--cc=bfields@fieldses.org \
--cc=bpm@sgi.com \
--cc=chris.mason@oracle.com \
--cc=cluster-devel@redhat.com \
--cc=davem@davemloft.net \
--cc=dchinner@redhat.com \
--cc=elder@kernel.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jlbec@evilplan.org \
--cc=konishi.ryusuke@lab.ntt.co.jp \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=mfasheh@suse.com \
--cc=miklos@szeredi.hu \
--cc=ocfs2-devel@oss.oracle.com \
--cc=swhiteho@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
--cc=xfs@os \
/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;
as well as URLs for NNTP newsgroup(s).