linux-ext4 - Re: [RFC] [PATCH] vfs: Call filesystem callback when backing device caches should be flushed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090121223546.GK16133@shareable.org>
Date:	Wed, 21 Jan 2009 22:35:46 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Tso <tytso@....EDU>
Subject: Re: [RFC] [PATCH] vfs: Call filesystem callback when backing device caches should be flushed

Joel Becker wrote:
> 	You make a fair point about journaling filesystems - except, of
> course, that they don't really use barriers; mount defaults or
> device-mapper often preclude them.  So people with 'incorrect' barrier
> configurations get no fsync() safety.

I think maybe it's fair enough that if barrier=no fsync() safety
doesn't use barriers either.  Barriers mean it's safe on power loss -
on most disks and some RAID controllers.  No barriers is still useful
- it's maybe safe on system crash but not power loss, with some
performance gained.  So it's fair that it can be an admin decision.

Maybe a separate generic mount option for fsync safety would be good
though.  Interestingly, Windows is documented as letting the
application choose (limited by the constraints of the hardware), and
so is MacOSX.  That makes sense too.

> 	Regarding "filesystems without a backing device", that's why I
> said "we have backing_dev_info".  We can tell what the backing device
> is; we should be able to determine that no flush is needed without
> modifying those filesystems.
> 
> >   Finally, I prefer maintainers of the filesystems themselves to decide
> > whether their filesystem needs flushing and thus knowingly impose this
> > performance penalty on them...
> 
> 	I understand what you're thinking here, but that way defaults to
> an unsafe fsync().  Thus you're causing broken behavior in the hopes
> that maintainers pay enough attention to fix the behavior.

In this area, because the symptom of broken behaviour rarely shows up,
and when it does you don't know this is the culprit, it won't get
fixed passively.  As Nick says, we've had other fsync() bugs for ages
too, and it's hard to test if it's really correct, yet it's quite
important.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html