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: Sat, 11 Jul 2015 10:40:29 -0600 [thread overview]
Message-ID: <CAPQXdDTT5E3f3VqAuQYKp3FwHjU45CfGW35du3HxRCHdyuz5gA@mail.gmail.com> (raw)
In-Reply-To: <3753681.2HYhjf7Zfa@merkaba>
On Sat, Jul 11, 2015 at 4:12 AM, Martin Steigerwald <martin@lichtvoll.de> wrote:
> Always do "sync" after a "btrfs fi defrag" and before measuring with
> "filefrag". The kernel may not have written everything. I have seen this
> repeatedly that the extent count drops further after a "sync", following
> "btrfs fi defrag".
First of all, thank you for your help. This fixed the problem for
defragging individual files.
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.
Transcript:
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ sync
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ filefrag
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-:
1567 extents found
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ time btrfs fi defrag
-r /home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--
real 0m0.006s
user 0m0.000s
sys 0m0.004s
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ sync
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ filefrag
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-:
1567 extents found
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ btrfs fi defrag
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ sync
eric@europa:~/filefrag/2015-07-11 09:53:32-06:00$ filefrag
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1MzDigXwKSteYI4y1XLf7qE--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1YygQLPowcpLwoNE.bCX4a---/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1rvNb.zifeXTwNQmAhQdkpU--/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1oFfB25Ypui-NUlhLrvnCu---/ECRYPTFS_FNEK_ENCRYPTED.FXbZ4j3re5lQYkQsG5UhAnMElrqSQB7o7Dt1e.GaDiBl08xl5bZAxYj09kaLyAQQuN1NY-zCYqLw21g-:
15 extents found
>> btrfs --version: Btrfs v3.17
>
> I recommend to update both :), but for the defragging it should not matter.
As long as it doesn't affect defragging, I think I'll stick with what
I've got. There isn't any critical data on this machine that I would
miss.
> […]
>> Terminal Transcript
>> -------------------
>>
>> eric@europa:~/filefrag/2015-07-09$ filefrag
>> /home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5Uh
> […]
>
> Nice, someone like me searching the correspondending file name in ecryptfs
> for defragmenting :)
I was kind of surprised that ecryptfs-find uses inode numbers and the
find command to locate the encrypted name of a file. It seems like
there should be a better, much faster way to do this.
Thanks,
Eric
next prev parent reply other threads:[~2015-07-11 16:40 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 [this message]
2015-07-12 8:54 ` Martin Steigerwald
2015-07-12 20:35 ` erpo41
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=CAPQXdDTT5E3f3VqAuQYKp3FwHjU45CfGW35du3HxRCHdyuz5gA@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).