>>>>> "Duncan" == Duncan <1i5t5.dun...@cox.net> writes:
Duncan> Tho as you point out elsewhere, levels under the filesystem Duncan> layer may split the btrfs 4096 byte block size into 512 byte Duncan> logical sector sizes if appropriate, but that has nothing to do Duncan> with btrfs except that it operates on top of that. The notion of "splitting into a different block size" is a bit confusing. The filesystem submits an N-byte I/O. Whether the logical block size is 512 or 4096 doesn't really matter. We're still transferring N bytes of data. The only thing the logical block size really affects is how we calculate the LBA and block counts in the command we send to the device. If N is not a multiple of the device's logical block size we'll simply reject the I/O. If we receive an I/O that is misaligned or not a multiple of the physical block size we let the drive do RMW. So there isn't any "splitting" going on. An I/O may be split if MD or DM is involved and the request straddles a stripe chunk boundary. Because Linux generally does all I/O in terms of 4K pages, sub-page size splits are rare. Pretty much all the other cases that would force us to split an I/O (typically controller DMA constraints) operate on a page boundary. To avoid the drive being forced to do RMW on the head and tail of a misaligned I/O it is imperative that the filesystems are aligned to the physical block size of the underlying device. As has been pointed out the partitioning utilities generally make sure that's the case. If there are no partitions then you're by definition aligned unless the drive has the infamous Windows XP jumper installed. Anyway. The short answer is that Linux will pretty much always do I/O in multiples of the system page size regardless of the logical block size of the underlying device. There are a few exceptions to this such as direct I/O, legacy filesystems using bufferheads and raw block device access. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
