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