Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jan 2002 13:11:00 +0000
From:      Brian Somers <brian@freebsd-services.com>
To:        Maxim Sobolev <sobomax@FreeBSD.org>
Cc:        des@ofug.org (Dag-Erling Smorgrav), mckusick@FreeBSD.org (Kirk McKusick), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@freebsd-services.com
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 
Message-ID:  <200201211311.g0LDB1r91545@hak.lan.Awfulhak.org>
In-Reply-To: Message from Maxim Sobolev <sobomax@FreeBSD.org>  of "Tue, 15 Jan 2002 16:02:05 %2B0200." <200201151403.g0FE3P321197@vega.vega.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > 
> > 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). :(((

I believe this occurs because when a program does open(O_TRUNC), 
write(), write(), write(), write(), write(), close(), each write 
that's committed to the softupdates queue is actually some block 
updates followed by an inode update.  Softupdates optimises out 
the previous inode update.

The initial inode update isn't optimised out (the truncate) so that 
the disk blocks can be freed easily.

So the queue ends up being:

  Make the file size 0
  Do a *load* of block updates
  Make the file size correct.

If you crash, you're *very* likely to end up with a zero length file.

This is unfortunate, and there's no easy way to avoid it.

> -Maxim

-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>



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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201211311.g0LDB1r91545>