All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi_debug: Thin provisioning
Date: Sat, 03 Oct 2009 09:49:49 -0400	[thread overview]
Message-ID: <4AC7567D.2080507@interlog.com> (raw)
In-Reply-To: <yq1eipldt0y.fsf@sermon.lab.mkp.net>

Martin K. Petersen wrote:
> scsi_debug: Thin provisioning support
> 
> Implement support for thin provisioning in scsi_debug.  No actual memory
> de-allocation is taking place.  The intent is to emulate a thinly
> provisioned storage device, not to be one.
> 
> There are four new module options:
> 
>  - unmap_granularity specifies the granularity at which to track mapped
>    blocks (specified in number of logical blocks).  2048 (1 MB) is a
>    realistic value for disk arrays although some may have a finer
>    granularity.
> 
>  - unmap_alignment specifies the first LBA which is naturally aligned on
>    an unmap_granularity boundary.
> 
>  - unmap_max_desc specifies the maximum number of ranges that can be
>    unmapped using one UNMAP command.  If this is 0, only WRITE SAME is
>    supported and UNMAP will cause a check condition.
> 
>  - unmap_max_blocks specifies the maximum number of blocks that can be
>    unmapped using a single UNMAP command.  Default is 0xffffffff.
> 
> These parameters are reported in the new and extended block limits VPD.
> 
> If unmap_granularity is specified the device is tagged as thin
> provisioning capable in READ CAPACITY(16).  A bitmap is allocated to
> track whether blocks are mapped or not.  A WRITE request will cause a
> block to be mapped.  So will WRITE SAME unless the UNMAP bit is set.
> 
> Blocks can be unmapped using either WRITE SAME or UNMAP.  No accounting
> is done to track partial blocks.  This means that only whole blocks will
> be marked free.  This is how the array people tell me their firmwares
> work.
> 
> GET LBA STATUS is also supported.  This command reports whether a block
> is mapped or not, and how long the adjoining mapped/unmapped extent is.
> 
> The block allocation bitmap can also be viewed from user space via:
> 
> 	/sys/bus/pseudo/drivers/scsi_debug/map
> 
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Acked-by: Douglas Gilbert <dgilbert@interlog.com>

  reply	other threads:[~2009-10-03 13:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-03  4:02 [PATCH] scsi_debug: Thin provisioning Martin K. Petersen
2009-10-03 13:49 ` Douglas Gilbert [this message]
2009-10-04  3:06 ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AC7567D.2080507@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.