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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).