Hello,
I read through the FAQ you mentioned, but I must admit, that I do not
fully understand.
My experience is that it takes a bit of time to soak in. Between time,
previous Linux experience, and reading this list for awhile, things do
make more sense now, but my understanding has definitely changed and
deepened over time.
Yes, I'm progressing. But I am a bit behind you :-)
What I am wondering about is, what caused this problem to arise. The
filesystem was hardly a week old, never mistreated (powered down without
unmounting or so) and not even half full. So what caused the data chunks
all being allocated?
I can't really say, but it's worth noting that btrfs can normally
allocate chunks, but doesn't (yet?) automatically deallocate them. To
deallocate, you balance. Btrfs can reuse areas that have been deleted as
the same thing, data or metadata, but it can't switch between them
without a balance.
Ok, I do understand that. I don't know why it could not automatically
deallocate them.. But then at least I'd expect it to automatically
detect this problem and do a balance, when needed.
Note, that this Problem caused my System to become unavailable and it
took days to find how to fix it (even if the fix was then very quick,
thanks to your help).
So the most obvious thing is that if you copy a bunch of stuff around so
the filesystem is nearing full, then delete a bunch of it, consider
checking your btrfs filesystem df/show stats and see whether you need a
balance. But like I said, that's obvious.
Yes. I did not really do much with the system. I copied everything onto
the filesystem, rebooted and let it run for a week.
The only thing that I could think of is that I created hourly snapshots
with snapper.
In fact in order to be able to do the balance, I had to delete something
-so I deleted the snapshots.
One possibility off the top of my head: Do you have noatime set in your
mount options? That's definitely recommended with snapshotting, since
otherwise, atime updates will be changes to the filesystem metadata since
the last snapshot, and thus will add to the difference between snapshots
that must be stored. If you're doing hourly snapshots and are accessing
much of the filesystem each hour, that'll add up!
Really? I do have noatime set, but I would expect the accesstime be
stored in the metadata. So when snapshotting, only the changed metadata
would have to be stored for the files that have been accesed between the
two snapshots. That should not be a problem, is it?
Additionally, I recommend snapshot thinning. Hourly snapshots are nice
but after some time, they just become noise. Will you really know or
care which specific hour it was if you're having to retrieve a snapshot
from a month ago?
In fact, snapper does that for me.
Also, it may or may not apply to you, but internal-rewrite (as opposed to
simply appended) files are bad news for COW-based filesystems such as
btrfs.
I don't see any applications that do internal re-writes on my system.
Interesting nevertheless, esp. wrt. the posible solution. Thaks.
Besides this:
You recommend monitoring the output of btrfs fi show and to do a
balance, whenever unallocated space drops too low. I can monitor this
and let monit send me a message once that happens. Still, I'd like to
know how to make this less likely.
I haven't had a problem with it here, but then I haven't been doing much
snapshotting (and always manual when I do it), I don't run any VMs or
large databases, I mounted with the autodefrag option from the beginning,
and I've used noatime for nearing a decade now as it was also recommended
for my previous filesystem, reiserfs.
The only differences are that my snapshotting is automated and the
autodefrag is not set. No databases, no VMs, noatime set. It's a simple
install of Ubuntu.
But regardless of my experience with my own usage pattern, I suspect that
with reasonable monitoring, you'll eventually become familiar with how
fast the chunks are allocated and possibly with what sort of actions
beyond the obvious active moving stuff around on the filesystem triggers
those allocations, for your specific usage pattern, and can then adapt as
necessary.
Yes, that's a workaround. But really, that makes one the slave to your
filesystem. That's not really acceptable, is it?
Regards,
Hendrik
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
