[lkml]   [2012]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/19 v5] Fix filesystem freezing deadlocks
    On Tue, Apr 17, 2012 at 11:32:46AM +0200, Jan Kara wrote:
    > 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.

    Let me add my name to the chorus of "we have to handle freezing
    with open+unlinked, we cannot assume they don't exist."

    > 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).

    Others have pointed out that we can flag the safe filesystems.
    I'd even be willing to say you can't freeze the unsafe filesystems.

    > 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.

    Given that frozen filesystems can stay that way for a while,
    couldn't that lead to a million frozen df(1)s? It's like your average
    NFS network failure.

    > 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.

    Perhaps we handle iput() like unlinked. If the filesystem can
    handle it, we allow it, otherwise we block.


    > 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 <>
    > SUSE Labs, CR


    "The first requisite of a good citizen in this republic of ours
    is that he shall be able and willing to pull his weight."
    - Theodore Roosevelt

     \ /
      Last update: 2012-04-17 21:37    [W:0.025 / U:6.596 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site