[stgt] [PATCHes] Updated patches for thin-provisioning support

[ronnie sahlberg]

Hi,

I think it should only be available if the user explicitely activates
it on the LUN.
The reason is that thin-provisioning is a bit dangerous if you are not careful.

When using thin-provisioning you have to constantly monitor the
underlying filesystem and that it is not running out of space.
Because if the underlying filesystem becomes full,  and WRITE10 calls
start failing, bad things will happen :-)



When using thin-provisioning, this should be done by a concious
choice, and the user should be aware of the risks
and the need to monitor that the filesystem does not become full.

I will write this up in a separate patch to the manpage to discuss the
pros and cons of thin provisioning and the risks associated with it
unless one is careful.


We should also in a later patch implement 4.7.3.8.1 tresholds so that
tgtd can tell thin-provisioning aware initiators when we are about to
run out of space   so that those initiators can produce BIG warnings
to the admin to "take action before it is too late" .



regards
ronnie sahlberg


On Mon, Apr 2, 2012 at 10:26 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Mon, 02 Apr 2012 09:06:11 +0900 (JST)
> FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> wrote:
>
>> On Sun, 1 Apr 2012 08:26:27 +1000
>> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>>
>>> From 2830abc3935294eba621b781f72aecda604c65a7 Mon Sep 17 00:00:00 2001
>>> From: Ronnie Sahlberg <ronniesahlberg at gmail.com>
>>> Date: Sun, 1 Apr 2012 08:04:06 +1000
>>> Subject: [PATCH 2/2] SBC UNMAP: Add support for thin-provisioning and the UNMAP command.
>>>
>>> The UNMAP command is implemented using FALLOC_FL_PUNCH_HOLE and will
>>> release UNMAPPED blocks back to the underlying filesystem.
>>>
>>> FALLOC_FL_PUNCH_HOLE is fairly new addition to Linux but works on
>>> ext4 and XFS filesystems currently.
>>>
>>> Signed-off-by: Ronnie Sahlberg <ronniesahlberg at gmail.com>
>>> ---
>>>  doc/tgtadm.8.xml |   25 ++++++++++++++
>>>  usr/bs_rdwr.c    |   97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  usr/sbc.c        |   76 +++++++++++++++++++++++++++++++++++++++++-
>>>  usr/scsi.h       |    1 +
>>>  usr/spc.c        |   43 +++++++++++++++++++++--
>>>  usr/target.c     |    2 +
>>>  usr/tgtd.h       |    2 +
>>>  7 files changed, 241 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/doc/tgtadm.8.xml b/doc/tgtadm.8.xml
>>> index 668e184..a40f659 100644
>>> --- a/doc/tgtadm.8.xml
>>> +++ b/doc/tgtadm.8.xml
>>> @@ -352,6 +352,31 @@ tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 1 \
>>>           --params readonly=1
>>>        </screen>
>>>
>>> +      <varlistentry><term><option>thin_provisioning=<0|1></option></term>
>>> +        <listitem>
>>> +          <para>
>>> +        This controls the provisioning for the LUN. A thin-provisioned
>>> +        LUN is represented as a sparse file.
>>> +        TGTD supports provisioning type 2 for sparse files.
>>> +        When initiators use the SCSI UNMAP command TGTD will release
>>> +        the affected areas back to the filesystem using
>>> +        FALLOC_FL_PUNCH_HOLE.
>>> +          </para>
>>> +          <para>
>>> +        This parameter only applies to DISK devices.
>>> +          </para>
>>> +          <para>
>>> +        Thin-provisioning only works for LUNs stored on filesystems
>>> +        that support FALLOC_FL_PUNCH_HOLE.
>>> +          </para>
>>> +        </listitem>
>>> +      </varlistentry>
>>> +
>>> +      <screen format="linespecific">
>>> +tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 1 \
>>> +         --params thin_provisioning=1
>>> +      </screen>
>>
>> Users need to enable this explicitly?
>>
>> I mean that when a lu is added, tgtd can check if the backing storage
>> supports FALLOC_FL_PUNCH_HOLE then enables it automatically?
>
> Note that I'm not against providing the explict option to users but
> normally users has the option for this (e.g. btrfs mount option) on
> the initiator side. So even if tgtd automatically enables this, users
> can avoid using this feature. So I wonder that it's worth providing
> the explict option.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html