From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752879AbZDVF3s (ORCPT ); Wed, 22 Apr 2009 01:29:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751611AbZDVF3j (ORCPT ); Wed, 22 Apr 2009 01:29:39 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:36008 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbZDVF3i (ORCPT ); Wed, 22 Apr 2009 01:29:38 -0400 From: KOSAKI Motohiro To: Eric Sandeen Subject: Re: [PATCH, RFC] check for frozen filesystems in the mmap path Cc: kosaki.motohiro@jp.fujitsu.com, linux-fsdevel , Linux Kernel Mailing List , Rik van Riel In-Reply-To: <49EEA4BE.6000207@redhat.com> References: <20090422132451.62A4.A69D9226@jp.fujitsu.com> <49EEA4BE.6000207@redhat.com> Message-Id: <20090422141250.62A7.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Date: Wed, 22 Apr 2009 14:29:24 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > KOSAKI Motohiro wrote: > >>> 2. this logic kill multi thread application. > >>> > >>> this logic mean mmap_sem grabbing until unfreeze. > >>> it mean othrer thread in the same process can't page-fault although > >>> it don't touch frozen-sb. > >>> it seems strange. > >> Hm, I hadn't thought about this ... On the one hand, ->page_mkwrite can > >> already sleep, though a userspace freeze/unfreeze could potentially take > >> much much longer. freeze/unfreeze *should* happen very quickly, but > >> nothing enforces that. > >> > >> Do you have any suggestions? > > > > One more comment. > > > > I read ioctl_fsfreeze() and freeze_bdev(), it call __fsync_super(). > > Oh, I don't think __fsync_suepr is very quick. > > Well, what I mean is that the filesystem is not intended to be frozen > for long periods of time. But it's not enforced by any method. > > > So, page-fault have one unique characteristics. > > if page-fault return 0 without pte change, page-fault is occur again soon. > > then, if you need long time waiting, I think you can use following technique. > > > > unlock mmap_sem > > wait long-time > > lock mmap_sem > > goto out; > > > > > > it cause page-fault counter increment twice unintesionally. > > but no problem. fs-freeze is not freqently event. > > > > Am I missing anything? > > Hm, I'll have to think about that. This is not my best area. :) So do > you mean that if a wait needs to happen for the frozen fs, we can > unlock, do that wait for unfreeze, relock, return early, and come back > again when it is not frozen? Yes. > One other thing that I think I just discovered is that nothing is > actually stopping mmap IO even on a frozen filesystem, as long as no > metadata updates are required for the IO... I'm seeing this on xfs > anyway (ext4 tries to update mtime, so that gets stopped on the frozen fs). I don't understand this issue. oh sorry, I'm not fs expert ;)