Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 May 2013 20:48:19 +0530
From:      Ajit Jain <ajit.jain@cloudbyte.com>
To:        Steven Hartland <killing@multiplay.co.uk>
Cc:        freebsd-fs <freebsd-fs@freebsd.org>
Subject:   Re: seeing data corruption with zfs trim functionality
Message-ID:  <CAA71u6YZAKrmfTLU32f8UmYecmydwiqRT-OrR1ukZ9V6PGsU%2Bw@mail.gmail.com>
In-Reply-To: <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk>
References:  <CAA71u6Y5dKZ9O0rqxCpx-9t7DYgTnPZSoNy-iHOnmzrOUYp%2Bvw@mail.gmail.com> <60316751643743738AB83DABC6A5934B@multiplay.co.uk> <20130429105143.GA1492@icarus.home.lan> <3AD1AB31003D49B2BF2EA7DD411B38A2@multiplay.co.uk> <C6AA4D0A7C49469ABB3C7440B1BCC108@multiplay.co.uk> <CAA71u6Zh7BbbdC=utqfR2MD1Nn=9euUDXHKqqu9NyBG-Jx%2B=Ow@mail.gmail.com> <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <CAA71u6ZuO9CF0ECFS4z07-E5qPea-6SfNwkvhr_g6pFT5MV5yQ@mail.gmail.com> <CAA71u6YKGHDRVg6W_xnCNaA68bJvAZ2Lkp-UisiPqb1vKjJhfA@mail.gmail.com> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Steven,

Thanks for the update.
It is surprising that there is no/less disk activity as the command is
correct. May be we need to enable
sync=always on the zfs dataset.

I will try again the once I update the cam code base.

regards,
ajit


On Wed, May 15, 2013 at 7:37 PM, Steven Hartland <killing@multiplay.co.uk>wrote:

> Unless you have the latest CAM patches, which is in current, you wont be
> doing TRIM on SATA disk connected to an LSI controller.
>
> I've just tested using the following cmd under 8.3 with MFC'ed changes from
> current, using ATA_TRIM, UNMAP & WS16 and have had no issues on a machine
> with Intel SSD and LSI controller.
> ./iotest -t 20 -s 536870912 -W 100 -T 500 /test/iotest/
>
> I did however notice that your test is hardly doing any disk access apart
> from when its "Initializing test file....", instead it seems to be CPU
> bound,
> so not sure if there's a problem with the iotest code or with my command
> line args?
>
> Given this my current thinking is either:
> 1. There's a problem with your patches 2. There's a bug in the FW of the
> Seagate disk
> 3. There's a problem with the UNMAP code which is being trigged by your
> disk
> only.
>
> I think #3 is quite unlikely.
>
> If you could install a recent version of current and test with that it
> should rule out #1, leaving #2.
>
>
>    Regards
>    Steve
>
> ----- Original Message ----- From: "Ajit Jain" <ajit.jain@cloudbyte.com>
>
>
>  Hi Steve,
>>
>> One more thing I am not seeing data corruption with SATA SSD (kingston).
>> The issue was seen on SAS SSD i.e. Seagate PULSAR ST100FM0002 .
>>
>> regards,
>> ajit
>>
>>
>> On Wed, May 15, 2013 at 1:49 PM, Ajit Jain <ajit.jain@cloudbyte.com>
>> wrote:
>>
>>  Hi Steven,
>>>
>>> Please find the tar ball of src code and binary of the test utility
>>> attached with the mail.
>>> Steps of test:
>>> 1. Enable zfs trim in /boot/loader.conf (vfs.zfs.trim_disable=0)
>>> 2. Set the delete method of the ssd device as UNMAP or WS16.
>>> 3. Create a pool (and optionally dataset) on the device.
>>> 4. Run iotest utility with thread count 10 (-t option) file size as at
>>> least 5GB
>>>     Second to execute as at least 500 sec (-T option) and write as 100%
>>> (W
>>> option).
>>>
>>> regards,
>>> ajit
>>>
>>>
>>> On Wed, May 15, 2013 at 12:56 PM, Steven Hartland <
>>> killing@multiplay.co.uk
>>> > wrote:
>>>
>>>  Could you provide us with details on the tests your using so we can
>>>> run them here on current sources and see if we see any issues?
>>>>
>>>>    Regards
>>>>    Steve
>>>>
>>>> ----- Original Message ----- From: "Ajit Jain" <ajit.jain@cloudbyte.com
>>>> >
>>>> To: "Steven Hartland" <killing@multiplay.co.uk>
>>>> Cc: "freebsd-fs" <freebsd-fs@freebsd.org>
>>>> Sent: Wednesday, May 15, 2013 6:47 AM
>>>>
>>>> Subject: Re: seeing data corruption with zfs trim functionality
>>>>
>>>>
>>>>  Hi Steven,
>>>>
>>>>>
>>>>> Thanks for the follow-up.
>>>>> The code where I pulled in zfs trim patches is not updated to 9 stable
>>>>> specially the cam directory.
>>>>> I pulled in many dependent patches in order to apply the patches that
>>>>> you
>>>>> gave. After that all da devices
>>>>> CAM_PERIPH_INVALID in dadone() because read capability was returning a
>>>>> very
>>>>> big number (bigger than MAXPHYS)
>>>>> for the block size. I think this is because I have not update the code
>>>>> to 9
>>>>> stable (only pulled in required patches and miss
>>>>> some patches).
>>>>>
>>>>> So, I am planning to first update my code to 9stable and then try the
>>>>> same
>>>>> test again. That might take some time.
>>>>>
>>>>>
>>>>> thanks again,
>>>>> ajit
>>>>>
>>>>>
>>>>> On Wed, May 15, 2013 at 2:40 AM, Steven Hartland <
>>>>> killing@multiplay.co.uk>****wrote:
>>>>>
>>>>>
>>>>>  ----- Original Message ----- From: "Steven Hartland"
>>>>>
>>>>>>
>>>>>>  What version are you porting the changes to?
>>>>>>
>>>>>>
>>>>>>>  What SSD are you using?
>>>>>>>>>
>>>>>>>>> What LSI controller are you using?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  I'd also like to see "zpool status" (for every pool that involves
>>>>>>>> this
>>>>>>>> SSD) and "gpart show" against the disk itself.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Also:
>>>>>>> 1. What FW version is your LSI? You can get this from dmesg.
>>>>>>> 2. The exact command line your running iotest with?
>>>>>>>
>>>>>>>
>>>>>>>  Any update on this? I'd like to try and replicate your test here so
>>>>>> would appreciate as much information as possible.
>>>>>>
>>>>>>
>>>>>>    Regards
>>>>>>    Steve
>>>>>>
>>>>>> ==============================******==================
>>>>>>
>>>>>>
>>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd.
>>>>>> and
>>>>>> the person or entity to whom it is addressed. In the event of
>>>>>> misdirection,
>>>>>> the recipient is prohibited from using, copying, printing or otherwise
>>>>>> disseminating it or any information contained in it.
>>>>>> In the event of misdirection, illegible or incomplete transmission
>>>>>> please
>>>>>> telephone +44 845 868 1337
>>>>>> or return the E.mail to postmaster@multiplay.co.uk.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>  ==============================****==================
>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and
>>>> the person or entity to whom it is addressed. In the event of
>>>> misdirection,
>>>> the recipient is prohibited from using, copying, printing or otherwise
>>>> disseminating it or any information contained in it.
>>>> In the event of misdirection, illegible or incomplete transmission
>>>> please
>>>> telephone +44 845 868 1337
>>>> or return the E.mail to postmaster@multiplay.co.uk.
>>>>
>>>>
>>>>
>>>
>>
> ==============================**==================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and
> the person or entity to whom it is addressed. In the event of misdirection,
> the recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to postmaster@multiplay.co.uk.
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA71u6YZAKrmfTLU32f8UmYecmydwiqRT-OrR1ukZ9V6PGsU%2Bw>