July 10, 2014 at 08:56Virtualbox virtualboxes on btrfs
A lot of time has passed since btrfs appeared. She is still in development. Pluses declared and already implemented the sea. Here you and transparent compression and pictures with one team and many more goodies. While there is no online defragmentation, but still I want to use it. I have been using my laptop desktop for root for a long time, probably already a year. Snapshots save from broken packages and other things like that. One acquaintance on a minnote even longer, because the built-in SSD doesn’t really interfere with his SSD, and here the compression is transparent. In general, this FS is quite stable today.
I finally decided to drag my volume with data onto it. A lot of text files, some kind of archives with source codes and stuff like that, will be compressed, and the speed of btrfs is not bad either. Decided yes done. Everything was just perfectly converted, then defragmentation, balancing the tree and free space on the hard drive became 100GB more than it was. The target was not in a free place, it was already gone for less than 200 GB, the goal was access speed. A powerful processor does not even notice the load from data compression, but on the screw, this data is stored as half as a result. Hence, less load on the screw and higher access speed. By the way, if you will transfer the FS to something, do not convert, but simply create an empty one and copy everything there. The fact is that tree defragmentation and balancing take a very long time, and the screw plows all this time like a damn. It’s better to temporarily merge the data into an intermediate one and then back.
In general, I was happy, but not for long. I have images of several virtual machines on this volume, it’s convenient to use them. Prots (i7) supports virtualization, and virtual machines for experiments are very useful. But at btrfs they refused to work categorically. Some sort of endless disk operations started and that’s all, the virtual machine is hanging something digesting there, I haven’t waited once when it finishes.
Naturally, I got to look for a solution. Mount options are recommended: nodatacow and compress = no. This will disable volume compression and CoW mode (the happiness of this FS, in addition to snapshots and other RAID-osti), so I absolutely did not like it. Plus, even with these options, btrfs and virtual machines (VirtualBox) did not get along well anyway. This is of course a flaw in the FS, I won’t begin to block it here.
As it turned out, everything can be solved not inside btrfs, but inside VirtualBox! It is enough to enable caching in the media settings of the virtual machine and everything plows perfectly with compression and in CoW btrfs mode. Although it seems that the documentation on VirtualBox says that the virtual SATA controller does not need caching, in this case it saves.
PS Yes, virtual computers are loaded now really much faster, which was originally required.
I finally decided to drag my volume with data onto it. A lot of text files, some kind of archives with source codes and stuff like that, will be compressed, and the speed of btrfs is not bad either. Decided yes done. Everything was just perfectly converted, then defragmentation, balancing the tree and free space on the hard drive became 100GB more than it was. The target was not in a free place, it was already gone for less than 200 GB, the goal was access speed. A powerful processor does not even notice the load from data compression, but on the screw, this data is stored as half as a result. Hence, less load on the screw and higher access speed. By the way, if you will transfer the FS to something, do not convert, but simply create an empty one and copy everything there. The fact is that tree defragmentation and balancing take a very long time, and the screw plows all this time like a damn. It’s better to temporarily merge the data into an intermediate one and then back.
In general, I was happy, but not for long. I have images of several virtual machines on this volume, it’s convenient to use them. Prots (i7) supports virtualization, and virtual machines for experiments are very useful. But at btrfs they refused to work categorically. Some sort of endless disk operations started and that’s all, the virtual machine is hanging something digesting there, I haven’t waited once when it finishes.
Naturally, I got to look for a solution. Mount options are recommended: nodatacow and compress = no. This will disable volume compression and CoW mode (the happiness of this FS, in addition to snapshots and other RAID-osti), so I absolutely did not like it. Plus, even with these options, btrfs and virtual machines (VirtualBox) did not get along well anyway. This is of course a flaw in the FS, I won’t begin to block it here.
As it turned out, everything can be solved not inside btrfs, but inside VirtualBox! It is enough to enable caching in the media settings of the virtual machine and everything plows perfectly with compression and in CoW btrfs mode. Although it seems that the documentation on VirtualBox says that the virtual SATA controller does not need caching, in this case it saves.
PS Yes, virtual computers are loaded now really much faster, which was originally required.