From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sakima.ivy.net ([69.31.131.60]) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1Lx42Q-0001Wr-0v for linux-mtd@lists.infradead.org; Thu, 23 Apr 2009 18:52:59 +0000 Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id E9980A8093 for ; Thu, 23 Apr 2009 14:21:41 -0400 (EDT) To: linux-mtd@lists.infradead.org Subject: Re: mtdblock caching and syncing References: <20090409141556.GG15952@nortel.com> <20090409145100.GB7538@yoda.jdub.homelinux.org> <20090409160247.GI15952@nortel.com> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Apr_23_14:21:40_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 23 Apr 2009 14:21:41 -0400 In-Reply-To: <20090409160247.GI15952@nortel.com> (Doug Graham's message of "Thu, 9 Apr 2009 12:02:47 -0400") Message-ID: List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --pgp-sign-Multipart_Thu_Apr_23_14:21:40_2009-1 Content-Type: text/plain; charset=US-ASCII >>>>> "dg" == Doug Graham writes: dg> I would assume that [hard drives] don't leave dirty data in dg> their cache for an unbounded period of time. ZFS always, ext3 mounted with barrier=1 (or by default in SLES only) and only when not using LVM2, and HFS+ on Mac OS X when using their bullshit fcntl F_FULLSYNC API, all at least claim to issue SYNC CACHE commands to the drives and wait for the drive to write to platter. It's also possible for people who care to turn off the write cache in their drives. For drives connected to RAID controllers that have a battery-backed write cache, I've hard of database-oriented sysadmins who actually do this as a best-practice not a freak experiment---in general, at least for SCSI drives, DBA's are likely to be aware of and control their drives' write cache settings. There is some FUD about drives existing that ignore the SYNC CACHE command (but not SCSI drives), but so far the people I've seen spreading this FUD refuse to name the specific drives, so they are likely to be really old drives, or even just made-up excuses from developers of buggy filesystems and block layers. Anyway, the point is, mtdblock is behind the curve here, yes. and for hard drive-backed filesystems the situation will probably get even better soon. And finally, devices which use FLASH tend to get their cords yanked more often so IMHO it matters. --pgp-sign-Multipart_Thu_Apr_23_14:21:40_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUASfCxtYnCBbTaW/4dAQKylAQAkA+mM918oqOGldG3KDd3ytl57D0KSsrL zXqxQB0stzo4HbWFOKWr1SwP2vqIDpU56Si3xoVr8uqjPkzE44Wplthv0XRItYBV aVU39+HKn2qa5yPGKfYpNZ1lzQnm7kP9UsaqHnj8CKgplxoLzXkrwJSYoYf5EczU sb+gC+oBVOg= =s7Bp -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Apr_23_14:21:40_2009-1--