I lost a picture of Bob Becks ass this same exact way.

-B

On Tue, Nov 10, 2009 at 1:29 AM, Nick Guenther <kou...@gmail.com> wrote:
> So, as nicely summarized at
> http://www.h-online.com/open/news/item/Possible-data-loss-in-Ext4-740467.html,
> ext4 is kind of broken. It won't honor fsync and, as a /feature/, will
> wait up to two minutes to write out data, leading to lots of files
> emptied to the great bitbucket in the sky if the machine goes down in
> that period. Why is this relevant to OpenBSD? Well sometimes I've been
> writing a file in vi or mg and had my machine go down, and when it
> comes back I find that the file is empty and I'm just trying to figure
> out if this is just because the data wasn't fsync'd or if it's because
> of softdep or what.
>
> I know this is kind of a newbish question but I have no idea how I'd
> go about researching it. And I'd like to sort this out because it's a
> big gap in my knowledge. I thought there was a paper on softdep but
> http://openbsd.org/papers doesn't have it.
>
> NetBSD's summary <http://www.netbsd.org/docs/misc/#softdep-impact> says:
> "The FFS takes care to correctly order all metadata operations, as
> well as to ensure that all metadata operations precede operations on
> the data to which they refer, so that the file system may be
> guaranteed to be recoverable after a crash. The last N seconds of file
> data may not be recoverable, where N is the syncer interval, but the
> file system metadata will be. N is usually 30."
>
> So my interpretation of this is that my missing file is a
> to-be-expected ancient part of posix, unless I run sync after every
> write. Is this right? Out of curiousity, what would happen if I ran
> sync and pulled the power at the same time (that is, what cases can
> cause the filesystem to get inconsistent)?
>
>
> But I still don't get how softdeps fits into all this. That page goes on:
>
> "With softdeps running, you've got almost the same guarantee. With
> softdeps, you have the guarantee that you will get a consistent
> snapshot of the file system as it was at some particular point in time
> before the crash. So you don't know, as you did without softdeps,
> that, for example, if you did an atomic operation such as a rename of
> a lock file, the lock file will actually be there; but you do know
> that the directory it was in won't be trashed and you do know that
> ordering dependencies between that atomic operation and future atomic
> operations will have been preserved, so if you are depending on atomic
> operations to control, say, some database-like process (e.g. writing
> mail spool files in batches, gathering data from a transaction system,
> etc.) you can safely start back up where you appear to have left off."
>
> but while I kind of grasp the details, I can't seem to figure out what
> they mean in context.
>
> Enlightenment appreciated! I don't want to be that guy in 20 years who
> rewrites the filesystem to be more efficient by not actually writing
> the quantum-light-platter.
>
> (and btw, why isn't http://openbsd.org/papers linked from the front page?)
>
> -Nick

Reply via email to