linux-ext4 - Re: [PATCH RFC] block: use discard if possible in blkdev_issue

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: <yq1lhx7n8r5.fsf@sermon.lab.mkp.net>
Date:	Tue, 18 Feb 2014 21:20:30 -0500
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	linux-fsdevel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH RFC] block: use discard if possible in blkdev_issue_discard()

>>>>> "Ted" == Theodore Ts'o <tytso@....edu> writes:

Ted,

Ted> Is it a fair assumption that the reason why T10 added these bits is
Ted> mainly so that clients of thin-provisioned storage devices can
Ted> guarantee that a subseq uent write won't fail? 

Yes. It's a way to lock down blocks for future use without having to
actually write them.

Ted> Figuring out when it's better to use fstrim, or doing it at unlink
Ted> time, etc., is something that's better done automatically instead
Ted> of manually, but this is I fear answering questions like this in a
Ted> reliable fashion is going to be a very hard problem

We'll quickly get back to the problem we had with the other I/O hints.
Namely the device vendor having to provide an honest indicator of their
performance characteristics.

Recent SCSI has a way to communicate maximum values for processing
various types of commands. Going forward we can use those values to tune
our request timeouts. But as far as the normal processing time is
concerned it's hard to see a vendor putting anything in there other than
"this one goes to 11".

Over time we may be able to switch to online discards by default. But at
this stage drives with queued trim support are just starting to roll
out. And some thin-provisioned arrays were evidently also designed with
a monthly Norton SpeedDisk run in mind.

However, I'm open to having a prefer_online_discards flag that dedicated
PCIe SSD drivers could set. It's not until we enter SCSI/ATA territory
that things get murky.

On the topic of reliable discards: Apparently there are some amendments
being discussed in T10/T13 right now that may help us. Still
investigating...

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