On 2016-03-15 18:29, Peter Chant wrote:
On 03/15/2016 03:52 PM, Duncan wrote:
Tho even with autodefrag, given the previous relatime and snapshotting,
it could be that the free-space in existing chunks is fragmented, which
over time and continued usage would force higher file fragmentation
despite the autodefrag, since there simply aren't any large contiguous
free-space areas left in which to write files.
Hmm. The following returns instantly as if it were a null operation.
btrfs fi defrag /
That should return almost immediately, as defrag isn't recursive by
default, and / should only have at most about 16-20 directory entries.
I thought though that btrfs fi defrag <name> would only defrag the one
file or directory?
It does, it's just not recursive unless you tell it to be.
btrfs fi defrag /srv/photos/
Is considerably slower, it is still running. Disk light is on solid.
Processes kworker and btrfs-transacti are pretty busy according to iotop.
If you have a lot of items in /srv/photos/ (be it either lots of
individual files, or lots of directories at the top level), then this is
normal, if not, then you may have found a bug.
Boot is an exception to the usual btrfs raid1, with a separate working
boot partition on one device and its backup on the other, so I can point
the BIOS at and boot either one. It's btrfs mixed-bg mode dup, 256 MiB
for each of working and backup, which because it's dup means 128 MiB
capacity. That's actually a bit small, and why I'll be shrinking the log
partition the next time I repartition. Making it 384 MiB dup, for 192
MiB capacity, would be much better, and since I can shrink the log
partition by that and still keep the main partitions GiB aligned, it all
works out.
Slackware uses lilo so I need a separate /boot with something that is
supported by lilo.
I would like to point out that just because the distribution prefers one
package doesn't mean you can't use another, it's just not quite as easy.
It's worth noting that I do similarly to Duncan in this respect
though, although I provisioned 512MiB when I set things up (and stuck
the BIOS boot partition (because I use GPT on everything these days) in
the unaligned slack space between the partition table and /boot). It
also has the advantage that I can fall back to old versions of the
kernel and initrd if need be when an upgrade fails to boot for some reason.
<snip>
If I had 500 GiB SSDs like the one you're getting, I could put the media
partition on SSDs and be rid of the spinning rust entirely. But I seem
to keep finding higher priorities for the money I'd spend on a pair of
them...
I'm getting one, not two, so the system is raid0. Data is more
important (and backed up).
If you don't need the full terabyte of space, I would seriously suggest
using raid1 instead of raid0. If you're using SSD's, then you won't get
much performance gain from BTRFS raid0 (because the I/O dispatching is
not particularly smart), and it also makes it more likely that you will
need to rebuild from scratch.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
