Usually on Habré write ready-made articles with answers, but I want to raise a question, the answer to which, it seems to me, will be negative.

The crux of the problem: Virtualization systems with a high degree of virtualization (I say this to sweep aside openvz) provide space for virtual machines in the form of a virtual disk. Or, more precisely, a virtual block device. Sometimes it is emulated tales (VMWare Server, Virtual PC), sometimes an “undefined block device”, sometimes with direct text “virtual disk” (Xen for PV-machines). It is important that this device completely repeats the properties of a block device - a set of sectors that can be read and written.

Most virtualization systems allow you to resize disks. Many systems allow you to do this on the go, online.
')
The question is: can the guest OS use this place freely? This question goes beyond virtualization and is a general question: do we have file systems that can dynamically change in size in the normal mode?



First, it must be said that most file systems can grow “on the go”. XFS, raiserfs, ext3-4 ... Some file systems may shrink (ext3, raiser ... xfs can not). Windows looks like a full outcaster here, as it does not support resizing the NTFS file system, especially on system disks. Third-party utilities are able to do it, but not on the go ...

But even white and fluffy ext3 can not do it in normal mode. It is necessary to use hands to say “otresayzit”, and the process of reysizing (especially, down) takes up huge resources. According to my personal impressions, resizing from 5.5TB to 4.5TB file system with 4TB of occupied space takes about 10-12 hours on conventional SATA disks. The increase works faster, in units of minutes. But - anyway, with a loss of performance, a large load and an unacceptably long time.

And the approach itself is incorrect. If we want to dynamically change the size of the used space, then we need a mechanism that would voluntarily free up unused space, in the normal mode of operation of the file system, and request a new one if necessary.

Existing Solutions

As far as I understand, there are no such file systems for block devices. The only solution is using file-based network access, in other words, using NFS / SMB for Unix and SMB for windows.

For block devices, as far as I understand, only the issue of “increase on demand” is partially and limitedly resolved. This is done with the help of a sparsed (sparse) disk image file, which is created of a much larger size than you plan to use - when recording additional information on such a disk, he begins to occupy a larger amount of actual space. For the guest OS, this disk does not change the size (at the same time it is larger than the actual occupied space). This method does not take into account the file system features at all, leads to the fragmentation of the image file and does not allow to give free space.

What really need

The file system should be as small as possible. If we have 2GB, then the size of the file system is 2GB + service data. If we decide to create a file of 100TB in size, the file system requests the block device of the underlying level of 25 billion blocks of 4Kb and places the file. When the file is erased, the file system will give the 25 billion back.

“LVM” comes to mind, but LVM does not currently support requests from the file system, and it is not at all ready to cut holes from the middle of FS ...

Questions

Question 1: Are there any file systems in which there is a similar solution?
Question 2: what should the file system interface and block devices look like?
Question 3: Is it possible to imagine the replacement of block devices with such a type of virtual devices, which on the one hand would allow creating and using file systems, on the other hand would be more adapted to dynamic resizing?
Question 4: how will such a device look like?