From: Phillip Susi <psusi@ubuntu.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Zheng Liu <gnehzuil.liu@gmail.com>,
linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>
Subject: Re: [PATCH 2/2] filefrag: count a contiguous extent when both logical and physical blocks are contiguous
Date: Tue, 19 Mar 2013 14:44:46 -0400 [thread overview]
Message-ID: <5148B21E.1050708@ubuntu.com> (raw)
In-Reply-To: <20130313201611.GH5604@thunk.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 3/13/2013 4:16 PM, Theodore Ts'o wrote:
> If we want to optimize the time to copy said sparse file, and if
> we assume that by the time we are defragging said sparse file, we
> are done doing writes which will allocate new blocks, then having
> defrag optimize the file so that when the extents are sorted by
> logical block number, the physical block numbers are contiguous,
> then that's probably the best "figure of merit" to use. And I'll
> note that right now that's what filefrag is reporting, and what I
> think e4defrag should be changed to use when deciding whether the
> donor file is "better" than the original file.
That's certainly exactly what I expect to get after defragging a file.
> But that's not necessarily the only way to measure extents, and
> the current e4defrag code is clearly of the opinion that if the
> file is using a contiguous region of blocks, even if the blocks
> were allocated "backwards", that there's no point defragging the
> file, since after all, if the file was written in such a random
> order with respect to logical block numbers, it will probably be
> read in a random order, so keeping the file blocks used contiguous
> to minimize free block fragmentation is the best thing to shoot
> for.
That seems wrong to me. It shouldn't matter what condition the file
starts in; the end should always be a file with blocks allocated in
the proper order. If there's no point in defragging a randomly
accessed file, then the user shouldn't bother running defrag on it,
and conversely, if they do, it should perform the task they requested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRSLIeAAoJEJrBOlT6nu7526UH/RTFmZWDXgrzGUwbbBJ1IN6t
aylOR1Wg3SWKEp5Cs717iHCNPMosF31bHkHG+MbpoSvJpAfRPZ7svTDTbzfBZ17F
dLKLOAYx3KRBeX8TSYIC7e5E/qTg1C6wmiS1Rlab5boeRkmUL/kP7WPpCgKHpydZ
tgUtzO7npCWVxP3eG9NnOR9y9U0PHuS3B9Q5S2vhbeqpxQnEi4cphoSw1bOJVcCj
RkddmEUuj+usDl8kHwxlyoiRhcwMUY59UuTqEWqgDkntQL5DTdX//AfrUdW3PBmB
DKIC4dCaoivXoKarKRuLaHM04rldOvZdxNFFNnoKlnQMhh4i82RnEYSio26778c=
=0Iea
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-03-19 18:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 16:26 [PATCH 0/2] fixup bugs in e2fsprogs that is reported by xfstests #218 Zheng Liu
2013-03-03 16:26 ` [PATCH 1/2] e4defrag: defrag a file when orig_physical_cnt == donor_physical_cnt Zheng Liu
2013-03-13 19:54 ` Theodore Ts'o
2013-03-03 16:26 ` [PATCH 2/2] filefrag: count a contiguous extent when both logical and physical blocks are contiguous Zheng Liu
2013-03-13 20:16 ` Theodore Ts'o
2013-03-14 12:54 ` Zheng Liu
2013-03-17 23:11 ` Dave Chinner
2013-03-19 18:44 ` Phillip Susi [this message]
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=5148B21E.1050708@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=gnehzuil.liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wenqing.lz@taobao.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).