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]
Date:	Fri, 8 Jun 2012 16:11:39 +0200
From:	Jan Kara <jack@...e.cz>
To:	Asdo <asdo@...ftmail.org>
Cc:	Phil Turmel <philip@...mel.org>, NeilBrown <neilb@...e.de>,
	linux-raid <linux-raid@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: Sync does not flush to disk!?

On Fri 08-06-12 15:57:04, Asdo wrote:
> On 06/08/12 15:49, Phil Turmel wrote:
> >
> >To put it another way:  You can't safely access ext filesystems via
> >raw devices in two systems.  The kernel cache won't be synchronized,
> >and you almost certainly *will* corrupt the contents.
> 
> Thanks both of you for your explanations
> 
> I might say that it seems to me a bad design: never before I saw a
> cache that is not updated by writes.
> Here the cache content is *older* than the data on the real devices!?
> if it was *newer*, there are known cases (writeback cache not
> flushed yet), but *older*... never seen.
  Well, the problem is in inconsistency of caches. There is one cache -
page cache - used by filesystems to read & write file data which is
addressed by inode, offset. And there is another cache caching the whole
device addressed by device, offset. It would be too costly to keep both
these caches consistent and most people don't care so we don't.

  BTW, if you configured KVM to use direct IO or virt IO when accessing the
devices (a good idea anyway), you wouldn't have the problems either.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ