From: Boaz Harrosh <bharrosh@panasas.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Douglas Gilbert <dgilbert@interlog.com>,
Jens Axboe <axboe@kernel.dk>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Mike Christie <michaelc@cs.wisc.edu>,
Hannes Reinecke <hare@suse.de>,
James Bottomley <James.Bottomley@suse.de>,
Konrad Rzeszutek Wilk <konrad@darnok.org>,
Richard Sharpe <realrichardsharpe@gmail.com>
Subject: Re: [PATCH 3/3] tcm/fileio: Add UNMAP / Block DISCARD support
Date: Wed, 29 Sep 2010 10:57:56 +0200 [thread overview]
Message-ID: <4CA2FF94.8020800@panasas.com> (raw)
In-Reply-To: <1285747739.18417.49.camel@haakon2.linux-iscsi.org>
On 09/29/2010 10:08 AM, Nicholas A. Bellinger wrote:
> On Tue, 2010-09-28 at 08:46 +0200, Boaz Harrosh wrote:
>>> + printk(KERN_WARNING "Ignoring UNMAP for non BD"
>>> + " backend for struct file\n");
>>
>> TODO: Lots of extent based filesystems could enjoy if you punch an hole
>> in the file. (Which will also send a proper discard).
>> So how to punch an hole in a file via vfs?
>
> Good question, as all of the current block discard support assumes a
> struct block_device * pointer currently.
>
> I know that hch has mentioned that accesing a struct block_device from
> struct file is very dangerous, but I am assuming for the TCM/FILEIO case
> that this code will be protected by igrab() and iput().
>
> hch and jaxboe, any comments here..?
>
No you did not understand. FILEIO (working on a filesystem's real file),
should *never* attempt a discard on the blocks even if it was
to read the file's map and figure out these blocks. It should always
call a filesystem specific API that puntches-an-hole in the file.
Fore stupid filesystem that means fill with zero's. For a smart
extent-based file system it means splitting up the extents the range
belongs to and freeing up the block that where allocated for that
range. But it is an heavy meta-data operation that only the filesystem
can do. With really smart FS like xfs the unallocated blocks also
get discarded, for when working with SANs with over provisioning.
> Thanks!
>
> --nab
Boaz
next prev parent reply other threads:[~2010-09-29 8:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 22:51 [PATCH 3/3] tcm/fileio: Add UNMAP / Block DISCARD support Nicholas A. Bellinger
2010-09-28 6:46 ` Boaz Harrosh
2010-09-29 8:08 ` Nicholas A. Bellinger
2010-09-29 8:57 ` Boaz Harrosh [this message]
2010-09-29 9:08 ` Nicholas A. Bellinger
2010-09-28 21:06 ` Rolf Eike Beer
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=4CA2FF94.8020800@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@suse.de \
--cc=axboe@kernel.dk \
--cc=dgilbert@interlog.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=konrad@darnok.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michaelc@cs.wisc.edu \
--cc=nab@linux-iscsi.org \
--cc=realrichardsharpe@gmail.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.