linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "erpo41@gmail.com" <erpo41@gmail.com>
To: Martin Steigerwald <martin@lichtvoll.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Defrag operations sometimes don't work.
Date: Sun, 12 Jul 2015 14:35:30 -0600	[thread overview]
Message-ID: <CAPQXdDT=T29uGvbWo6CXTuj-chDBAcr2ii5GCdhfrz35R-mEsQ@mail.gmail.com> (raw)
In-Reply-To: <11405054.0T05W1bXEO@merkaba>

On Sun, Jul 12, 2015 at 2:54 AM, Martin Steigerwald <martin@lichtvoll.de> wrote:
> Note however: Even without "sync" BTRFS will defragment the file. It may
> just take a while till the new extents are written. So there is no need to
> call "sync" after btrfs fi defrag.

My purpose in calling sync in that transcript was to ensure each
invocation of filefrag returned the correct results.

> Why are you trying to defragment anyway? What are you trying to achieve /
> solve?

There are several reasons. Some are technical and some are emotional.

Technical reason 1: I sometimes play computer games that are delivered
through Steam. If you're not familiar with it, Steam is a sort of
online storefront application for Linux and other platforms that--I
believe--delivers game patches by overwriting selected ranges in each
game's files. Lots of small overwrites are the main culprit behind
small files with thousand or tens of thousands of fragments on btrfs.
All I know for sure is that some game files have become heavily
fragmented and load times seem excessive, especially given that
they're older games compared to my hardware.

Technical reason 2: Whenever a new Ubuntu release comes out, I make
sure to download and burn the ISO before I upgrade my OS. Usually I
download the ISO using bittorrent, which uses lots of random writes
creating heavily fragmented downloads that severely impact read speeds
from my non-SSD hard disk. This increases my load quite a bit when I
seed the download back to other people. I've solved this problem in
the past by pausing the bittorrent client, copying the file to another
location, deleting the original, moving the copy back into place with
the same name, and resuming the client, but that's a pain. I'd rather
defragment instead.

Emotional reason 1: Heavily fragmented files on rotating media just
feel slovenly to me, like a person wearing dirty clothes or a bathroom
that hasn't been cleaned in a while.

Emotional reason 2: I switched from Windows to Linux in the late 90s.
At that time, RAM was expensive, so I often found myself in situations
where my kernel was dropping pages from the filesystem cache to make
room for application memory. Rereading those files later was very slow
if they were fragmented, so I religiously defragmented my Windows 95
and 98 machines every week. When I switched to Linux, I was dismayed
to learn that ext2 had no defragmentation tool, and I was very
skeptical of claims that "Linux doesn't need defragmentation",
especially considering that most of the people making those claims
probably had no idea how fragmented their own filesystems were. In the
years that followed, I was continually disappointed as stable
defragmentation tools did not appear for ext2 or any other popular
Linux filesystems, so I'm relieved and excited not to be in that
predicament anymore.

>> I'm now seeing that recursive defragging doesn't work the way I expect.
>> Running
>>
>> $ btrfs fi defrag -r /path/to
>>
>> returns almost immediately and does not reduce the number of fragments
>> in /path/to/file. However, running
>>
>> $ btrfs fi defrag /path/to/file
>>
>> does reduce the number of fragments.
>
> Well, I have no idea about this one. I have the same behavior with
>
>> >> btrfs --version: Btrfs v3.17
>
> v4.0

Thanks for checking,
Eric

      reply	other threads:[~2015-07-12 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-11  1:12 Defrag operations sometimes don't work erpo41
2015-07-11 10:12 ` Martin Steigerwald
2015-07-11 16:40   ` erpo41
2015-07-12  8:54     ` Martin Steigerwald
2015-07-12 20:35       ` erpo41 [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='CAPQXdDT=T29uGvbWo6CXTuj-chDBAcr2ii5GCdhfrz35R-mEsQ@mail.gmail.com' \
    --to=erpo41@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=martin@lichtvoll.de \
    /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).