[ale] Ubuntu Linux Defrag EXT4

[Pat Regan]

On Tue, 14 Sep 2010 00:16:45 -0400
"Michael B. Trausch" <mike at trausch.us> wrote:

> I was using it for awhile, but then I ran into a rather nasty bug that
> remained unfixed for some time, and I went back to using ext4.
> 

I toyed with it a little back in February or so.  There was no proper
snapshot removal.  I was toying with the idea of creating snapshots and
just going the slow route and doing an `rm -rf` to delete snapshots.
That was fine except btrfs was getting pretty slow as the snapshot
count increased.

Now I've been running it for root and home for probably close to two
months now without any problems.  I wonder if I need one of those "No
file system corruption in X days" posters :).

> However, when I was using it, I was taking advantage of the COW
> capability of the FS quite a bit.  My daily work was _much_ faster,
> and the way that I did things changed quite a lot to take advantage
> of the ability to cheaply create snapshots of individual files and
> modify them and throw them away if desired.  It is the ultimate
> filesystem for managing something like a VM on, particularly if that
> VM runs Windows, because you can do all the snapshoting and moving
> and deleting and reverting with complete transparency to the VM
> monitor.  It really is very nice.

At the moment it is the exact opposite of the ultimate file system for
running virtual machines...  There's some sort of bug/feature when
running kvm/qemu disk images on top of btrfs.  For me, watching iostat
in the guest sit in the tens of KB per second on writes was keeping the
host at a constant steady 1MB+ per second write load...

IIRC, you can eliminate this problem if you turn off barriers.  It
sounds like turning off barriers pretty much guaranties a corrupt
file system if the file system isn't unmounted cleanly...

I don't know if the problem is more or less noticeable with spinning
media, though.

I don't work with large numbers of virtual machines like I used to a
few years ago (I barely fire any up at all anymore).  I was really
hoping I could use btrfs snapshots, and deduplication when it is
available, to reduce the footprint and increase the speed of my virtual
disks (every shared block is a bit of shared cache).

> I'm looking forward to going back to trying it again; the bugs that I
> ran into before are (so I hear, anyway) completely fixed now, and I
> should be able to safely use the filesystem in a multi-device layout
> as I was previously.  I'm looking forward to the day that btrfs
> becomes the preferred stable filesystem, myself.

I'm running an awesome and simple little script called `btrfs-snap`.  I
thought I was going to have to script automated snapshots on my own but
btrfs-snap is nearly perfect.  I'm keeping 24 hourly, 7 daily, and 4
weekly snapshots of three volumes on my laptop.

Unfortunately (fortunately?), running btrfs has me even more paranoid
about running backups...  So I am saving time by getting free instant
"backups" but I'm spending more time making running rdiff-backup than
ever...

> I never did get around to trying btrfs' online defragmentation
> support, but I suspect that I won't need that in majority of the
> "normal" use cases that I have; fragmentation isn't a problem on my
> own personal workstations on any other filesystem that I have run on
> in the past, despite the number of files (and megabytes/gigabytes
> contained therein) that I have growing significantly in the past
> several years.  The only real problem that I have with the extX
> family is that it isn't versatile enough for me, after having had a
> taste of btrfs.  ;-)

I am imagining that VM disk images stored with COW enabled are going to
get very fragmented very quickly.

I'm thinking that fragmentation isn't likely to be a huge problem even
on spinning media.  I imagine it might be worthwhile to derfragment
database files once every month or quarter or so, maybe...

Pat