Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Oct 2011 19:12:59 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        Kirk McKusick <mckusick@mckusick.com>, Attilio Rao <attilio@freebsd.org>, Xin LI <delphij@freebsd.org>, freebsd-fs@freebsd.org
Subject:   Re: Need to force sync(2) before umounting UFS1 filesystems?
Message-ID:  <CAGH67wS%2BAW9zYnq=KQzKoVSfM5Oiax%2Bej=tfJ5BvjZHzb6zavA@mail.gmail.com>
In-Reply-To: <20111010093543.GV1511@deviant.kiev.zoral.com.ua>
References:  <CAGH67wSYmcxJCbTMVL%2BqWzbLojiCiBmRF98yaNL4b3d3LbvbYw@mail.gmail.com> <201110012137.p91Lb6FI093841@chez.mckusick.com> <CAGH67wS9G5Co%2BCjaVWrc-VX-mmp7CoEo0Cw7ysqpwkOMowRYCQ@mail.gmail.com> <CAGH67wSfgQ%2BDg0qQxkiKh4Uzt3E_J3rRL_=2PkbNvB=ii1f0LQ@mail.gmail.com> <20111010093543.GV1511@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/10/10 Kostik Belousov <kostikbel@gmail.com>:
> On Sun, Oct 09, 2011 at 03:37:22PM -0700, Garrett Cooper wrote:
>> On Sun, Oct 9, 2011 at 3:22 PM, Garrett Cooper <yanegomi@gmail.com> wrot=
e:
>> > On Sat, Oct 1, 2011 at 2:37 PM, Kirk McKusick <mckusick@mckusick.com> =
wrote:
>> >>> Date: Sat, 1 Oct 2011 12:44:04 -0700
>> >>> Subject: Re: Need to force sync(2) before umounting UFS1 filesystems=
?
>> >>> From: Garrett Cooper <yanegomi@gmail.com>
>> >>> To: Attilio Rao <attilio@freebsd.org>
>> >>> Cc: Kostik Belousov <kostikbel@gmail.com>,
>> >>> =A0 =A0 =A0 =A0 Kirk McKusick <mckusick@mckusick.com>, freebsd-fs@fr=
eebsd.org,
>> >>> =A0 =A0 =A0 =A0 Xin LI <delphij@freebsd.org>
>> >>>
>> >>> Ok. Now that I know this is the direction you guys want to go, I'll
>> >>> start testing the change.
>> >>
>> >> Thanks for throwing some testing at this. Please test my latest
>> >> proposed change (included below so you do not have to dig through
>> >> earlier email) as I believe that it has the least likelyhood of
>> >> problems and is what I am currently proposing to put in.
>> >
>> > I apologize for not getting this done sooner. It passes a smoke test
>> > with the following filesystems:
>> >
>> > nfs
>> > nullfs
>> > smbfs
>> > unionfs
>> > ufs
>> > zfs
>> >
>> > I'll be running more extensive stress tests soon, but it looks like a
>> > good step forward.
>>
>> Forgot to note: my FreeNAS builds nanobsd no longer fail with the
>> attached patch after I remove my sync hacks :).
>
> The real case to test is the NFS mount which is wedged due to
> hung/unresponsive NFS server. I have high suspect that the patch
> could introduce the unkillable hung unmount process.

    It blocked, but I could ^C it perfectly fine. I tested it via:

Setup:
1. Started up FreeNAS 8.x image; it acquired an IP from my server with
dhcp-75.local.

Test 1:
1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation.
2. Paused VM.
3. umount /mnt/nfs (the command blocked).
4. ^C.
5. mount | grep /mnt/nfs showed nothing (it had unmounted).

Test 2:
1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation (block=
ed).
2. Opened up another ssh session and cd'ed to /mnt/nfs .
3. Paused VM.
4. umount /mnt/nfs . It failed with EBUSY.
5. mount | grep /mnt/nfs showed that it was still mounted, as expected.

    So unless there are buffers still waiting to be written out to an
NFS share, or other reasons that would prevent the NFS share from
being fully released, I doubt the proposed behavior is really
different from previous versions of FreeBSD.
Thanks,
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wS%2BAW9zYnq=KQzKoVSfM5Oiax%2Bej=tfJ5BvjZHzb6zavA>