On 2012-04-16, at 5:43 PM, Dave Chinner wrote: > On Mon, Apr 16, 2012 at 03:02:50PM -0700, 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... > > Unlinked-but-open files are the reason that XFS dirties the log > after the freeze process is complete. This ensures that if the > system crashes while the filesystem is frozen then log recovery > during the next mount will process the unlinked (orphaned) inodes > and free the correctly. i.e. you can still freeze a filesystem with > inodes in this state successfully and have everythign behave as > you'd expect. > > I'm not sure how other filesystems handle this problem, but perhaps > pushing this check down into filesystem specific code or adding a > superblock feature flag might be a way to allow filesystems to > handle this case in the way they think is best... The ext3/4 code has long been able to handle open-unlinked files properly after a crash (they are put into a singly-linked list from the superblock on disk that is processed after journal recovery). The issue here is that blocking freeze from succeeding with open- unlinked files is an unreasonable assumption of this patch, and I don't think it is acceptable to land this patchset (which IMHO would prevent nearly every Gnome system from freezing unless these apps have changed their behaviour in more recent releases). Like you suggest, filesystems that handle this correctly should be able to flag or otherwise indicate that this is OK, and allow the freeze to continue. For other filesystems that do not handle open-unlinked file consistency during a filesystem freeze/snapshot whether this should even be considered a new case, or is something that has existed for ages already. The other question is whether this is still a problem even for filesystems handling the consistency issue, but from Jan's comment above there is a new locking issue related to mmap_sem being added? Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
