lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Feb 2009 16:13:42 -0800 (PST)
From:	david@...g.hm
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
cc:	"H. Peter Anvin" <hpa@...or.com>, Matthew Wilcox <matthew@....cx>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	sandeen@...hat.com
Subject: Re: ATA support for 4k sector size

On Wed, 25 Feb 2009, Martin K. Petersen wrote:

>>>>>> "david" == david  <david@...g.hm> writes:
>
>>> 512-byte logical / 512-byte hardware (current) 512-byte logical /
>>> 4096-byte hardware (ATA, doing read-modify-write) 4096-byte logical /
>>> 4096-byte hardware (SCSI initially, ATA later)
>
> david> add to this good support for SSDs
>
> david> ?? logical / 128K hardware
>
> david> or similar.
>
> Yep.  And that goes for RAID arrays too.
>
> For SCSI there some knobs we can query to get this information and my
> alignment changes are using those (and they are in turn what Willy's
> stuff hooks into).
>
> I've been lobbying the SSD vendors whose architecture is prone to
> misalignment problems to propose a similar set of knobs for ATA.  But so
> far it's just been a lot of talking.

even if we can't get them to give us any info from the drive directly, we 
still want to allow the sysadmin to configure the use of the systems when 
they can find the info in other ways.

> My topology changes are a bit abstract in the sense that they expose:
>
> - smallest I/O you can submit without incurring a penalty (hw sector,
>   raid chunk size)
>
> - optimal I/O size for the device in question
>
> - biggest I/O you can submit without incurring a penalty
>
> - alignment
>
> We can use these parameters to lay out partitions and filesystems
> optimally.  Just like we currently do with XFS but implemented in a more
> generic way that all filesystems can use.

if you have the smallest and largest I/O you can submit without a penalty 
and the alignment, isn't the optimal I/O size everything between these 
two? (or at least everything between these two may be close enough that 
defining an 'optimal' size may not be worthwhile)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists