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 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.