From: Valerie Aurora Henson <vaurora@redhat.com>
To: Nick Dokos <nicholas.dokos@hp.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/5][64-BIT] Miscellaneous e2fsprogs 64-bit patches - description
Date: Wed, 15 Apr 2009 15:50:14 -0400 [thread overview]
Message-ID: <20090415195014.GB1668@shell> (raw)
In-Reply-To: <11629.1239227147@alphaville.usa.hp.com>
On Wed, Apr 08, 2009 at 05:45:47PM -0400, Nick Dokos wrote:
> [I submitted the first three of these last week, but the first one,
> although the fix was correct (in the sense of fiddling with the correct
> bits), stylistically and from the point of code conventions and
> readability, was rather a botch. #2 and #3 are identical as patches but
> I fixed up parts of the commentary that were wrong or misleading. So I
> am reposting these as well as a couple of new ones. Please let me know
> if there are other problems of this sort. Thanks!]
Hi Nick,
Thanks for the testing and patches! I apologize for the delay in
replying; if it's any consolation, we were all at the Linux file
systems workshop when you sent this email.
All the patches look good to me (and I will ACK them individually). I
pulled them into my shared-64bit branch at:
http://git.kernel.org/?p=fs/ext2/val/e2fsprogs.git;a=summary
> P.S. Here is an interesting side issue:
>
> Patch 3 mentions that e2image ran to completion after the patch was applied
> (btw, in addition to the 16TiB file, the fs contains a directory with about
> 10^7 zero length files):
>
> # time e2image -r /dev/mapper/bigvg-bigvol /dev/null
> e2image 1.41.4-shared-64bit (27-Jan-2009)
>
> real 37m18.991s
> user 15m21.148s
> sys 17m57.151s
>
> but there is an interesting catch-22: how do I save its output?
>
> I can try the command line suggested in the manual page:
>
> e2image -r <dev> - | bzip2 > image.bz2
>
> but it takes forever: I started a run on Saturday and it was not
> done by Tuesday when I killed it - writing to the pipe at 4096 bytes
> a pop is very slow.
>
> Or I can forego the compression and try to save to a file: it's sparse
> (I only used 7GiB before it failed), but its nominal size exceeded the
> maximum file size limit on ext4, at which point I start getting lseek
> failures.
The 16TB limit on ext4 files is an enormous pain for testing 64-bit
(>= 16TB) file systems. I keep intending to write some simple dm
setup to concatenate two loopback files together, but instead I always
install XFS and create a loopback file on an XFS partition.
-VAL
next prev parent reply other threads:[~2009-04-15 19:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 21:45 [PATCH 0/5][64-BIT] Miscellaneous e2fsprogs 64-bit patches - description Nick Dokos
2009-04-15 19:50 ` Valerie Aurora Henson [this message]
2009-04-15 19:56 ` Eric Sandeen
2009-04-15 22:16 ` Valerie Aurora Henson
2009-04-16 0:31 ` Theodore Tso
2009-04-15 21:51 ` Nick Dokos
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=20090415195014.GB1668@shell \
--to=vaurora@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=nicholas.dokos@hp.com \
--cc=tytso@mit.edu \
/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.