From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: [Not TLS] Re: mount option nodatacow for VMs on SSD?
Date: Tue, 29 Nov 2016 05:14:18 +0000 (UTC) [thread overview]
Message-ID: <pan$a292d$fa229462$80743716$b85be0fd@cox.net> (raw)
In-Reply-To: 2df2e8e6-5ac4-a9c0-70bc-406fd84e9784@cobb.uk.net
Graham Cobb posted on Mon, 28 Nov 2016 09:49:33 +0000 as excerpted:
> On 28/11/16 02:56, Duncan wrote:
>> It should still be worth turning on autodefrag on an existing somewhat
>> fragmented filesystem. It just might take some time to defrag files
>> you do modify, and won't touch those you don't, which in some cases
>> might make it worth defragging those manually. Or simply create new
>> filesystems, mount them with autodefrag, and copy everything over so
>> you're starting fresh, as I do.
>
> Could that "copy" be (a series of) send/receive, so that snapshots and
> reflinks are preserved? Does autodefrag work in that case or does the
> send/receive somehow override that and end up preserving the original
> (fragmented) extent structure?
Very good question that I don't know the answer to as I've not seen it
discussed previously. (I'm not a dev, just a list regular and user of
btrfs myself, and my personal use-case involves neither snapshots nor
send/receive, so on those topics if I've not seen it covered previously
either here or on the wiki, I won't know.)
Someone else know?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-11-29 5:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 8:28 mount option nodatacow for VMs on SSD? Ulli Horlacher
2016-11-25 12:01 ` Duncan
2016-11-25 12:25 ` Roman Mamedov
2016-11-26 10:27 ` Kai Krakow
2016-11-28 0:38 ` Ulli Horlacher
2016-11-28 2:56 ` Duncan
2016-11-28 9:49 ` [Not TLS] " Graham Cobb
2016-11-29 5:14 ` Duncan [this message]
2016-11-29 10:34 ` [Not TLS] " Niccolò Belli
2016-11-29 12:18 ` [Not TLS] " Austin S. Hemmelgarn
2016-11-28 8:20 ` Kai Krakow
2016-11-28 11:11 ` Niccolò Belli
2016-11-29 5:06 ` Duncan
2016-11-29 12:20 ` Austin S. Hemmelgarn
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='pan$a292d$fa229462$80743716$b85be0fd@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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.