Re: Putting very big and small files in one subvolume?

[Martin <m_btrfs@ml1.co.uk>]

Good questions and already good comment given.


For another view...

On 17/08/14 13:31, Duncan wrote:
> Shriramana Sharma posted on Sun, 17 Aug 2014 14:26:06 +0530 as excerpted:
> 
>> Hello. One more Q re generic BTRFS behaviour.
>> https://btrfs.wiki.kernel.org/index.php/Main_Page specifically
>> advertises BTRFS's "Space-efficient packing of small files".
>>
>> So far (on ext3/4) I have been using two partitions for small/regular
>> files (like my source code repos, home directory with its hidden config
>> subdirectories etc) and big files (like downloaded Linux ISOs,
>> VMs etc) under some sort of understanding that this will help curb
>> fragmentation...

The cases of pathological fragmentation by btrfs (for 'database-style'
files and VM image files especially) have been mentioned, as have the
use of nocow and/or using separate subvolumes to reduce or slow down the
buildup of the fragmentation.

systemd logging even bulldozed blindly into that one spectacularly!...


There is now a defragment option. However, that does not scale well for
large or frequently rewritten files and you gamble how much IO bandwidth
you can afford to lose rewriting *entire* files.

The COW fragmentation problem is not going to go away. Also, there is
quite a high requirement for user awareness to specially mark
directories/files as nocow. And yet then, that still does not work well
if multiple snapshots are being taken...!


Could a better and more complete fix be to automatically defragment say
just x4 the size being written for a file segment?

Also, for the file segment being defragged, abandon any links to other
snapshots to in effect deliberately replicate the data where appropriate
so that data segment is fully defragged.



>> In any case, since BTRFS effectively discourages usage of separate
>> partitions to take advantage of subvolumes etc, and given the above
>> claim to the FS automatically handling small files efficiently, I wonder
>> if it makes sense any longer to create separate subvolumes for such
>> big/small files as I describe in my use case?
> 
> It's worth noting that btrfs subvolumes are a reasonably lightweight 
> construct, comparable enough to ordinary subdirectories that they're 
> presented that way when browsing a parent subvolume, and there was 
> actually discussion of making subvolumes and subdirs the exact same 
> thing, effectively turning all subdirs into subvolumes.
> 
> As it turns out that wasn't feasible due not to btrfs limitations, but 
> (as I understand it) to assumptions about subdirectories vs. mountable 
> entities (subvolumes) built into the Linux POSIX and VFS levels...

Due to namespaces and inode number spaces?...



> OTOH, I tend to be rather more of an independent partition booster than 
> many.  The biggest reason for that is the too many eggs in one basket 
> problem.  Fully separate filesystems on separate partitions...

I do so similarly myself. A good scheme that I have found to work well
for my cases is to have separate partitions for:

/boot
/var
/var/log
/
/usr
/home
/mnt/data...

And all the better and easy to do using GPT partition tables.

The one aspect to all that is that you can protect your system becoming
jammed by suffering a full disk for whatever reason and all without
needing to resort to quotas. So for example, rogue logging can fill up
/var/log and you can still use the system and be able to easily tidy
things up.

However, that scheme does also require that you have a good idea of what
partition sizes you will need right from when first set up.

You can 'cheat' and gain flexibility at the expense of HDD head seek
time by cobbling together LVM volumes as and when needed to resize
whichever filesystem.


Which is where btrfs comes into play in that if you can trust to not
lose all your eggs to btrfs corruption, you can utilise your partition
scheme with subvolumes and quotas and allow the intelligence in btrfs to
make everything work well even if you change what size (quota) you want
for a subvolume. The ENTIRE disk (no partition table) is all btrfs.

Special NOTE: Myself, I consider btrfs *quotas* to be still very
experimental at the moment and not to be used with valued data!



Other big plusses for btrfs for me are the raid and snapshots.

The killer though is for how robust the filesystem is against corruption
and random data/hardware failure.

btrfsck?


Always keep multiple backups!

Regards,
Martin