Hi, I'm planning to test bcache like this: 8x SATA drives md RAID10 bcache lvm ext3/ext4 Recent LVM versions have these two settings: > # By default, if a PV is placed directly upon an md device, LVM2 > # will align its data blocks with the md device's stripe-width. > # 1 enables; 0 disables. > md_chunk_alignment = 1 > > # By default, the start of a PV's data area will be a multiple of > # the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs. > # - minimum_io_size - the smallest request the device can perform > # w/o incurring a read-modify-write penalty (e.g. MD's chunk size) > # - optimal_io_size - the device's preferred unit of receiving I/O > # (e.g. MD's stripe width) > # minimum_io_size is used if optimal_io_size is undefined (0). > # If md_chunk_alignment is enabled, that detects the optimal_io_size. > # This setting takes precedence over md_chunk_alignment. > # 1 enables; 0 disables. > data_alignment_detection = 1 ... so will bcache pass the correct settings up to lvm via sysfs? When creating ext* filesystems on top of mds I currently use this: http://busybox.net/~aldot/mkfs_stride.html ... and I was wondering if bcache's metadata will be OK with this? Also, I noted that in the bcache.txt it says that discard is off by default because " SATA TRIM is an unqueued command (and thus slow)". I see that SATA v3.1 includes a queued trim/discard command, but I don't know if Linux yet has the support for it (there are a few SSDs with SATA v3.1 support on the market I think). Tim. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
