Re: [OT] Hard Drive Energy Not Worth Conserving drives?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> # 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