>> # hdparm -I /dev/sdc | grep "Sector size" >> Logical Sector size: 512 bytes >> Physical Sector size: 4096 bytes
> This is reported by the drive to hdparm. Only the 512 is used by the > kernel. It has no knowledge of the 4KB physical block size and can't > use it because the drive reports 512 bytes to the kernel as the > physical block size. Isn't it rather than the kernel chooses to only use the logical sector size? Where/when does the drive report 512B physical sector sizes? In any case, the issue is probably not really in the kernel but in the filesystems and partitioning tools: all that's really needed to use the drive efficiently is for fdisk/parted and for mkfs to be told (and make use of) the physical block size. Of course, maybe a good way to provide this info is to teach the kernel about it so those tools don't need to use side-band info via hdparm. >> Don't we already waste that space with our filesystems? Ext2 cannot use >> blocks smaller than 1024 Bytes, as far as I can see. And by default even >> 4kB are used for small filesystems (<5GB on my /). > This depends on the FS and how it allocates space for files. Indeed: for mail servers, there are 2 issues: - actual disk space use, which does not have to depend on the block size (file systems can use sub-blocks, they just often elect not to). > traditional 512 byte/sector disk. XFS can pack multiple small files > into a single 4KB block extent. It is able to do this thanks to > delayed allocation. Indeed, and for that reason 4KB physical blocks wouldn't cause additional disk space usage. - performance accessing those small files. Arguably, when accessing such small files, the bandwidth is typically low, so even in the worst case where 4KB blocks increase the bandwidth by a factor 8, it's still not necessarily going to be part of the bottleneck. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvd3o2ycsu.fsf-monnier+gmane.linux.debian.u...@gnu.org