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] [day] [month] [year] [list]
Date:	Thu, 08 Mar 2012 12:01:50 -0500
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Andreas Dilger <aedilger@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [RFC] fadvise: add more flags to provide a hint for block allocation

>>>>> "Dave" == Dave Chinner <david@...morbit.com> writes:

Dave> 2TB chunks, IIRC - the lower 32 bits of the 48bit LBA was intended
Dave> to be the relative offset into the region (RBA), with the upper 16
Dave> bits being the region number.

Correct.


>> However, that was shot down pretty hard.

Dave> That's unfortunate - it maps really well to how XFS uses
Dave> allocation groups.

The proposal met a lot of resistance. To the extent that the SMR folks
were asked to develop a new command set instead of using the standard
SCSI Block Commands.

I still think we can get most of what you want out of the static access
hints, however.


Dave> So the current proposal hides all the physical characteristics of
Dave> the devices from the file system and remaps the LBA internally
Dave> based on the IO hint? But that is the opposite direction to what
Dave> we've been taking over the past couple of years - we want more
Dave> visibility of device characteristics at the filesystem level so we
Dave> can optimise the filesystem better, not less.

The standards bodies are trying to avoid having to special-case handling
of shingled drives since they are only a transitional technology with a
short life expectancy.

We're getting close to the 8-year mark for 4K logical block size
transition and it hasn't happened yet. And at this stage it looks like
it might not happen at all (in the consumer space at least).

So I am not entirely convinced that SMR drives will still be relevant
when the standards have been ratified and the filesystems of the world
adapted to work with them.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ