Edward shishkin is a developer that has been in charge of maintaining Reiser4 file system support for the last decade for new kernel versions. Although the system has been maintained, unlike other file systems that have advanced in their development. Edward Shishkin worked in the maintenance of Reiser4 and at the same time I work on development for the Reiser5 filesystem which already it is available for testing.
This new version of Reiser5 stands out for including innovation in parallel scaling, which is carried out not at the block level, but through the filesystem.
As an advantage of this approach, non-parallel FS + RAID / LVM and FS packages are declared free of inherent drawbacks (ZFS, Btrfs), such as free space problem, performance sinking when filling volume above 70%, outdated logical volume design algorithms (RAID / LVM), does not allow you to efficiently distribute data on a volume logical.
In a parallel FS, before adding a device to a logical volume, it must be formatted with the standard mkfs utility.
Unlike ZFS, Reiser5 does not implement its own block layer, even though it uses a free block allocator O (1). It is possible to compose in a simple and efficient waye a logical volume from block devices of different sizes and bandwidths. The data is distributed between these devices using new algorithms.
In the announcement of this trial version Edward Shishkin commented:
I am pleased to announce a new method of adding block devices to logical volumes on a local machine.
I think it's a qualitatively new level in file system (and operating system) development: local volumes with parallel scaling ...
In our approach, horizontal scaling is done by file system means, rather than block layer means. The user controls the flow of I / O requests issued for each device ...
As Edward Shishkin comments: a portion of the I / O requests directed to each device equals its relative capacity assigned by the userso that the logical volume is filled with the data "evenly" and "fairly".
At the same time, lower-capacity block devices receive fewer blocks for storage, and lower-performance devices do not become a bottleneck (as is the case, for example, in RAID arrays).
Adding a device to the volume and removing the device from the volume is accompanied by a rebalancing that preserves the "fairness" of the distribution.
All included block devices can be simultaneously maintained on the logical volume using an individual approach for each of them (defragmenting for hard drives, posting discard queries for SSD, etc.).
Free space on a logical volume is controlled by the standard df (1) utility. In addition, the user has the opportunity to monitor the free space on each component of the logical volume device.
Significant progress in horizontal scaling was made using the parallel network file (GPFS, Luster, etc.). However, it was not clear, how to apply
your technologies to a local FS.Mainly, it is because in a local file systems don't have as much luxury as "back-end storage" as network they do. What the local FS has is an extremely poor interface of interaction with the block layer. For example, on local Linux FS you can just compose and issue an I / O request against some buffer.
Among the items that are still in the TODO list of Reiser5 are:
- FSCK upgrade to support logical volumes
- Asymmetric LV with more than one block of metadata per volume
- symmetric logical volumes
- 3D snapshots of LV
- Distribution of metadata across multiple subvolumes
- Check / restore logical volumes using fsck utility (upgrading from previous version)
- Global volumes (networks), adding devices on different machines.
If you want to know more about it, you can consult the following link.
Wow, I thought reiserfs had died after Hans ..