linux-ext4 - Re: [RFC] fadvise: add more flags to provide a hint for block allocation

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]

Message-ID: <yq1linbf2m9.fsf@sermon.lab.mkp.net>
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