From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: Thin provisioning & arrays Date: Tue, 11 Nov 2008 08:59:31 -0500 Message-ID: <49198FC3.7080301@redhat.com> References: <28572.1226369378@ocs10w> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Black_David@emc.com, david@fromorbit.com, dwmw2@infradead.org, martin.petersen@oracle.com, chris.mason@oracle.com, jens.axboe@oracle.com, James.Bottomley@hansenpartnership.com, linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org, coughlan@redhat.com, matthew@wil.cx To: Keith Owens Return-path: In-Reply-To: <28572.1226369378@ocs10w> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Keith Owens wrote: > On Mon, 10 Nov 2008 20:23:17 -0500, > Black_David@emc.com wrote: > >> Dave, >> The thin provisioning chunk size (coming) in the VPD page is a >> possible place to start. >> > > VPD page for which device? Consider a filesystem that is striped > across devices from multiple arrays or even multiple vendors. How is > the filesystem supposed to "align" an unmap command when the underlying > disks all have different alignments? > > I think that we are losing focus on the core use case here. Big arrays that implement thin luns also implement RAID in the box. If you are building a clustered file system, it would be extremely unlikely to build it with storage from different vendors. You always have the option to disable thin luns or simply fully provision LUN's for more complex situations. Thing is being pitched to answer a very specific customer use case - shared storage (mid to high end almost exclusively) with several different users and applications.... ric