All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Avantika Mathur <mathur@linux.vnet.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ext4 devel interlock meeting minutes (April 23, 2007)
Date: Tue, 24 Apr 2007 09:27:11 -0500	[thread overview]
Message-ID: <462E13BF.7040703@redhat.com> (raw)
In-Reply-To: <462D42CA.50509@linux.vnet.ibm.com>

Avantika Mathur wrote:
> - large filesystem
>     - We would like to perform more testing on large (>16TB) filesystems
>     - currently hardware limitations are preventing this testing.  We 
> have tested 10TB raid dists, and 16TB loopback devices.  Avantika will 
> look into creating very large sparse devices for testing.

I've been hacking up some ext3@16T testing scripts to use sparse
devicemapper devices which make use of snapshots... loopback files don't
work for testing, at least not hosted on ext[234], because we still
can't do these large file offsets.

(Documentation/device-mapper/zero.txt in the kernel tree describes these
sparse dm devices)

Testing the whole range as a sparse snapshot can be slow, since
devicemapper has to do all the exception handling etc, and I think
essentially creates a fragmented block device.

I've been playing with something like this:

# 90% of the real device size is used for a "real" 1:1 mapping
# The other 10% is sparsely mapped out to add up to totalsize.
# i.e. -

#                          [large sparse-ish device]
#
# +----------------------~  ~-----------------------------------------+
# |                     sparse                |         real          |
# +----------------------~  ~-----------------------------------------+
#
# |<------------ SPARSE_SIZE ---------------->|<----- REAL_SIZE ----->|

# is mapped on top of:

#                           [real block device]
#                      +----------------------------+
#                      | sp |       real            |
#                      +----------------------------+

and then marking the sparse range as full (maybe via lazy_bg, or other
methods).  You could then also put a dm-error target under the "full"
sections so that any IO that may stray there will fail.

This way you can direct the real IO to the 1:1 mapping portion of the
large dm device, and shouldn't get the snapshot slowdowns.

Anyway, just something I've been playing with...

-eric

  parent reply	other threads:[~2007-04-24 14:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 23:35 Ext4 devel interlock meeting minutes (April 23, 2007) Avantika Mathur
2007-04-24  6:00 ` Alex Tomas
2007-04-24 14:04   ` Valerie Clement
2007-04-24 14:21     ` Alex Tomas
2007-04-24 14:51       ` Valerie Clement
2007-04-24 14:27 ` Eric Sandeen [this message]
2007-04-30 11:06 ` Aneesh Kumar
2007-04-30 11:13   ` Alex Tomas
2007-05-01 12:08   ` Kalpak Shah

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=462E13BF.7040703@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mathur@linux.vnet.ibm.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.