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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120307171135.GB11457@thunk.org>
Date:	Wed, 7 Mar 2012 12:11:36 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	Sunil Mushran <sunil.mushran@...cle.com>,
	Zheng Liu <gnehzuil.liu@...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

On Wed, Mar 07, 2012 at 09:51:27AM +0100, Lukas Czerner wrote:
> Exactly, first we have to define what we actually need to achieve with
> it. Not just randomly making up stupid pseudo-optimizations. Moreover
> there is _no way_ file system has the information about the HSM nor the
> flash regions, fast regions or whatever, it does not even know where is
> the beginning of the disk. Stop constructing building from the roof!!
> There just is not any interface for the file system to use to get such
> information!

I'm not really worried about this problem.  This is something which
can easily be set by the system administrator via mkfs or tune2fs.
And just as we now have /sys/block/sda/queue/rotational so that upper
layers can make optimizations based on whether or not a disk is an
SSD, as we can prove that manual configuration of storage attributes
can make a measurable difference, it can be a spur to the standards
bodies to eventually (years and years and years later) come up with a
standardized way for the file system to get such interfaces
automatically.

In the meantime, we have flash vendors (or at least one flash vendor
who works with embedded/handset customers) interested in potentially
providing private interfaces to make additional storage attributes
available, or for file systems to provide information to the storage
devices so they can better optimize their behaivor.

So I'm not too worried about the fact that we don't have a way to
specify all of these things yet.  If we can find a way to make things
faster, eventually the rest of the infrastructure can get plumbed in.
(Even standards bodies that move in geologic time scales.  :-)

> I also believe that regarding HSM user is in no damn position to decide
> whether his file will be on flash or not. It just does not work that
> way, every user's, or application's files has to be accessed faster than
> others from their point of view.

Access control is going to be an interesting problem, and what the
requirements are for a file system running on an HPC system, or an
Android device, or a generic time-sharing system are quite different.
Given that many of us have grown up in an environment where there are
mutually suspicious (and untrustworthy) time sharing users, or equally
untrustworthy application writers who tend to optimize their
application without considering anything else, it's easy for us to
assume that if we can't solve the authorization problem completely,
that it's hopeless.

But the same argument can be made for real time scheduling priorities
(which is even easier for untrustworthy application authors to abuse),
but that's turned out to be extremely important in allowing Linux to
break through in various new fields --- including Naval Warships and
laser-wielding industrial robots.  :-)

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