VirtualBox VirtualBox on btrfs
Much time has passed since btrfs appeared. She is still in development. Pluses declared and already implemented the sea. Here you and the compression is transparent and pictures of one team, and many more buns. There is no online defragmentation yet, but I still want to use it. On the root of my laptop-desktop for a long time use, probably already a year. Snapshots save from broken packets and other things like that. One acquaintance on the mini-foot has even longer, since his built-in SSD doesn’t really fit anything, and here the compression is transparent. In general, this FS is fairly stable today.
I finally decided to drag my data volume onto it. A lot of text files, some archives with source files and other such compression will shake, but the speed of btrfs is not bad either. Decided yes did. Everything was just perfectly converted, then defragmentation, balancing the tree and free space on the hard disk was 100GB more than it was. The goal was not in the free space, it was already gone for less than 200GB, the goal was in access speed. A powerful processor does not even notice the burden of data compression, but on the screw, this data as a result is stored in half. Hence, less load on the screw and higher access speed. By the way, if you translate a file system to something, do not convert, but simply create an empty one and copy everything there. The fact is that the defragmentation and balancing of a tree takes a very long time, and the screw all this time plows like a damn. It is better to temporarily merge data into an intermediate one and then back.
In general, I was happy, but not for long. I have on this volume images of several virtual women, it is convenient with them. Proc (i7) supports virtualization, and virtuals are very useful for experiments. But on btrfs they refused to work flatly. Some kind of endless disk operations started and that's all, the virtual machine is hanging over something digesting, I didn’t wait until it was finished.
Naturally, I found a solution. Recommend mount options: nodatacow and compress = no. This will disable the compression of volumes and CoW mode (the most happiness from this FS, in addition to snapshots and other RAID-spy), so I absolutely did not like it. Plus, even with these options btrfs and virtuals (VirtualBox) did not get along normally anyway. This is of course a flaw in the FS, I will not begin to shield it here.
As it turned out, everything can be solved not inside btrfs, but inside VirtualBox! It is enough to turn on caching in the settings of the virtual media carrier and everything plows perfectly with both compression and CoW btrfs mode. Although it seems to be written in the documentation for VirtualBox that the virtual SATA controller does not need to be cached, in this case it saves.
PS Yes, virtual players are loaded now really much faster, which was originally required.
I finally decided to drag my data volume onto it. A lot of text files, some archives with source files and other such compression will shake, but the speed of btrfs is not bad either. Decided yes did. Everything was just perfectly converted, then defragmentation, balancing the tree and free space on the hard disk was 100GB more than it was. The goal was not in the free space, it was already gone for less than 200GB, the goal was in access speed. A powerful processor does not even notice the burden of data compression, but on the screw, this data as a result is stored in half. Hence, less load on the screw and higher access speed. By the way, if you translate a file system to something, do not convert, but simply create an empty one and copy everything there. The fact is that the defragmentation and balancing of a tree takes a very long time, and the screw all this time plows like a damn. It is better to temporarily merge data into an intermediate one and then back.
In general, I was happy, but not for long. I have on this volume images of several virtual women, it is convenient with them. Proc (i7) supports virtualization, and virtuals are very useful for experiments. But on btrfs they refused to work flatly. Some kind of endless disk operations started and that's all, the virtual machine is hanging over something digesting, I didn’t wait until it was finished.
Naturally, I found a solution. Recommend mount options: nodatacow and compress = no. This will disable the compression of volumes and CoW mode (the most happiness from this FS, in addition to snapshots and other RAID-spy), so I absolutely did not like it. Plus, even with these options btrfs and virtuals (VirtualBox) did not get along normally anyway. This is of course a flaw in the FS, I will not begin to shield it here.
As it turned out, everything can be solved not inside btrfs, but inside VirtualBox! It is enough to turn on caching in the settings of the virtual media carrier and everything plows perfectly with both compression and CoW btrfs mode. Although it seems to be written in the documentation for VirtualBox that the virtual SATA controller does not need to be cached, in this case it saves.
PS Yes, virtual players are loaded now really much faster, which was originally required.
')
Source: https://habr.com/ru/post/229335/
All Articles