[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <adafxbu3vqt.fsf@cisco.com>
Date: Fri, 14 Aug 2009 14:56:26 -0700
From: Roland Dreier <rdreier@...co.com>
To: Greg Freemyer <greg.freemyer@...il.com>
Cc: Richard Sharpe <realrichardsharpe@...il.com>, david@...g.hm,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Matthew Wilcox <willy@...ux.intel.com>,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Nitin Gupta <ngupta@...are.org>, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
Linux RAID <linux-raid@...r.kernel.org>
Subject: Re: Discard support
> It seems to me that unmap is not all that different, why do we need to
> do it even close in time proximity to the deletes? With a bitmap, we
> have total timing control of when the unmaps are forwarded down to the
> device. I like that timing control much better than a cache and
> coalesce approach.
The trouble I see with a bitmap is the amount of memory it consumes. It
seems that discards must be tracked on no bigger than 4KB sectors (and
possibly even 512 byte sectors). But even with 4KB, then, say, a 32 TB
volume (just 16 * 2TB disks, or even lower end with thin provisioning)
requires 1 GB of bitmap memory. Which is a lot just to store, let alone
walk over etc.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists