From owner-cvs-all  Sun Feb 10 21:50:14 2002
Delivered-To: cvs-all@freebsd.org
Received: from beastie.mckusick.com (adsl-64-173-27-61.dsl.sntc01.pacbell.net [64.173.27.61])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2134037B402; Sun, 10 Feb 2002 21:50:07 -0800 (PST)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id g1B5N8i06332;
	Sun, 10 Feb 2002 21:23:08 -0800 (PST)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200202110523.g1B5N8i06332@beastie.mckusick.com>
To: Maxim Sobolev <sobomax@FreeBSD.ORG>
Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/ufs/ffs ffs_inode.c ffs_vfsops.c src/sys/ufs/ufs ufs_inode.c ufs_vnops.c 
Cc: des@ofug.org (Dag-Erling Smorgrav), cvs-committers@FreeBSD.ORG,
	cvs-all@FreeBSD.ORG
In-Reply-To: Your message of "Tue, 15 Jan 2002 16:02:05 +0200."
             <200201151403.g0FE3P321197@vega.vega.com> 
Date: Sun, 10 Feb 2002 21:23:08 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

    From: Maxim Sobolev <sobomax@FreeBSD.ORG>
    Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/ufs/ffs ffs_inode.c ffs_vfsops.c src/sys/ufs/ufs ufs_inode.c ufs_vnops.c
    To: des@ofug.org (Dag-Erling Smorgrav)
    Date: Tue, 15 Jan 2002 16:02:05 +0200 (EET)
    Cc: mckusick@FreeBSD.ORG (Kirk McKusick), cvs-committers@FreeBSD.ORG,
       cvs-all@FreeBSD.ORG

    > 
    > Kirk McKusick <mckusick@FreeBSD.org> writes:
    > >   Log:
    > >   When downgrading a filesystem from read-write to read-only, operations
    > >   involving file removal or file update were not always being fully
    > >   committed to disk. The result was lost files or corrupted file data.
    > >   This change ensures that the filesystem is properly synced to disk
    > >   before the filesystem is down-graded.
    > 
    > Thank you, thank you, thank you, thank you!

    Could we have similar behaviour (i.e. data syncing) when going into a
    sleep mode? Several days ago I've lost a file that I saved right before
    my battery went low and then for some reason the system refused to resume
    properly after a sleep. BTW, I wonder how it's possible on a softupdates
    fs - my understanding was that I should have either older or newer version
    of the file - not obsolutely useless zero-sized file (and nothing in
    /lost+found). :(((

    -Maxim

What soft updates guarrantees is that you do not end up with a file
full of garbage. You may get one of zero length if the data has not
been written. Applications (like editors) are supposed to do fsync
before removing the old copy. Specifically, they should do the
equivalent of:

	write file.new
	fsync file.new
	rename file.new file

and if you want to make sure that the name file will refer to the
new contents rather than the old ones:

	fsync file

		Kirk McKusick

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message