On Mon, Apr 11, 2011 at 11:23:23AM -0700, Mark Busheman wrote: > Thanks Ted for replying. > > >> FUA doesn't cause a cache flush. > > Thanks for correcting. Yes FUA does not flush cache. When the FUA > bit is set in the write command, the drive make sure that the data > goes to platters and not to be put into its cache for latter writes. For that particular write only; and it forces the write to go directly to the disk, bypassing any seek-mitigation algorithms the disk might use. It's good if you only have a very small number of sectors (ideally one) which you need to write to the disk. In the case of ext4, we want to make sure all of the data and metadata blocks sent to disk are flushed down to the platters, so FUA isn't as useful to us, and so we don't use it. > >> Ext4 does send cache flush commands, or barriers, to make sure the data written to disk > >> is flushed all the way down to the disk platters on transaction commits. > I have few questions on this and need help: > a. To achieve the above, is any specific options that need to be used > while mounting? No, not for ext3. > b. Are the above mentioned things done only for data=journal or for > other modes such as > data=ordered and writeback? It's done for all journalling modes. > c. Are they done for metadata, journal and data writes? Yes; see below. > d. Can I know what are the commands sent to the drives to do the cache > flush commands > or barriers? Would like to find if the drive support the commands? We use the CACHE FLUSH or CACHE FLUSH EXT command, as appropriate for IDE/SATA disks. There is an equivalent command for SCSI, but in essence it establishes a barrier; all writes sent to the disk before the CACHE FLUSH/CACHE FLUSH EXT must be written to the disk before the barrier returns. When we use journaling, we send a CACHE FLUSH just before the writing the commit block, and then we send a second CACHE FLUSH after writing the commit block. (I suppose we could use a FUA bit for the commit block, which might be a slight optimization if there is any other writes happening in parallel that don't need to be affected, but it doubt it would make a huge difference in most cases.) > e. Is the above true also for ext3 - I posted a similar question to > ext3 forum and have got no > response so far? ext3 unfortunately defaults to barriers being disabled by default. Some distributions, such as the enterprise distro's such as RHEL and SLES, will enable ex3 barriers by default. You can use the mount option "barrier" to enable barriers at mount time with ext3, if you want to be sure barriers are enabled. With ext4, if you want to disable barriers for some reason (say you are confident the system has a dead reliable UPS and you need the performance), you can use the mount option nobarrier. (It enables barriers by default.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html