[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq17h82n6gs.fsf@sermon.lab.mkp.net>
Date: Thu, 30 Jun 2011 21:18:59 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Allison Henderson <achender@...ux.vnet.ibm.com>
Cc: Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data
>>>>> "Allison" == Allison Henderson <achender@...ux.vnet.ibm.com> writes:
>> Does sb_issue_zeroout() use the SCSI "write same" feature in the
>> background? That would avoid busying the CPU/controller/bus with
>> writing out zeroes, which might be expensive for a large file.
>>
Allison> Hmm, that's a good question, I will dig into it and see if I
Allison> can find out.
This is a bit of an ongoing project.
Unfortunately WRITE SAME is quirk central as many drives only implement
block ranges corresponding to what RAID vendors told them they needed.
Many of the drives I tested have internal caps at 16 or 32MB and will
fail in interesting (i.e. not necessarily graceful) ways if given bigger
ranges.
I've been lobbying for a way for devices to report their WRITE SAME
limit for a while. That feature finally made it into the latest SBC3
draft. The changes required to support it went into the SCSI layer
during the last merge window. What remains is wiring this up to
blkdev_issue_zeroout(). I have some patches sitting in my queue that I
hope to get polished and submitted soon.
Anyway. From a filesystem perspective sb_issue_zeroout() interface is
definitely the way to go. WRITE SAME will eventually be called if the
device supports it.
--
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