[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1y6d579fy.fsf@sermon.lab.mkp.net>
Date: Wed, 21 Jul 2010 00:20:01 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Christof Schmitt <christof.schmitt@...ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Jens Axboe <axboe@...nel.dk>, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [patch 0/1] Apply segment size and segment boundary to integrity data
>>>>> "Christof" == Christof Schmitt <christof.schmitt@...ibm.com> writes:
Christof> To have a simple approach that covers the case with one
Christof> integrity data segment per user data segment, we only report
Christof> half the size for the scatterlist length when running
Christof> DIX. This guarantees that the other half can be used for
Christof> integrity data.
Yup, a few of our partners did something similar.
My concern is the scenario where we submit lots of 512-byte writes that
get merged into (in your case) 4 KB segments. Each of those 512-byte
writes could come with an 8-byte integrity metadata tuple. And so you'd
need 8 DI scatterlist elements per data element.
Christof> Meaning the integrity data sg list would have more entries
Christof> than max_segments? I have not seen this during my experiments,
Christof> but then i likely have not hit every case of a possible
Christof> request layout.
dd to the block device is usually a good way to issue long scatterlists.
Christof> Ok, i have to look into that as well. It would be an issue
Christof> with the approach we are looking at now: If there are
Christof> max_segments data segments, and more than max_segments
Christof> integrity data segments, we will overrun the hardware
Christof> constraint.
Ok.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists