ext3cow file system

recently caught the eye of an interesting file system - ext3cow . I decided to make a small review. The ext3cow file system implements an additonal function to ext3 functionality - a time shift.

Those. This is some combination of the version control system and the file system. This is what the documentation says:

In time-shifting, it gives a continuous view of time. You can specify the name of any point in time, for example. The time-shifting interface allows you to create snapshots and access versions. Applications may need to coordinate snapshots with application state. User-space tools are suitable for automation, using software as simple as cron.

One of the features of the system is its versatility - the section can be enabled without changes in the kernel, only by dynamically loading the module. This is possible from the file system structure.

how it works from the user:

the user at a certain point in time who wished to backup the file / s executes the command
[user@host]: snapshot
Snapshot on . 1067992521

(with or without parameter — specific file or all files)
')
This command creates on the disk a version of the data that is currently relevant (the date is returned in the Unix-era format). This is called the epoch snapshot .
Further changes to the file can also be saved and will be saved in another epoch (which is remarkable - file changes are not saved within one epoch, i.e. backup at will, but based on ext3 capabilities - no more than 1 snapshot per second This is a significant difference between this file system and version control systems (subversion, for example).
Reading a file of a certain era looks like this:
[user@host]: cat somefile@1067992521

You can view a list of epochs in which there are versions of a specific file using the command
[user@host]: ls file@

Those. as if on the file system, all versions of the file are stored under the names file @ TIME , which is quite correct from the point of view of the file system model in the kernel.
Because interesting things are possible -

• snapshots can be mounted as directories. quote:
  

  It can be created using links, that is, you can create your own snapshots or snapshots.
  namespaces in separate volumes. For example, an administrator might create a read-only
  installing new software.

  
  
• tree a thing of the past:
  

  It is permissible to have multiple times, eg / A / B @ time1 / C / D @ time2 / E.

  
  

It should be noted that backup versions are immutable and read-only.
the operating system (page cache) looks at one file, all backup copies of which are created only on the disk.

how it works from the inside:
The main difference between ext3cow and ext3 is an increase in the amount of meta-information in i-nodes (offtop: oh, remembering Simonenko and the third retake :)). Quote:

ext3cow doesn’t need to be replaced by the Linux model, therefore it’s possible to integrate data structures or interfaces. Modi fi cations are limited to on-disk metadata and the in-memory fi le system speci fi c fi elds of the VFS metadata. Ext3cow adds directory entries, directory entries, and scrolling inheritance.

Further:

Both on-disk and in-memory inodes were recited to support snapshot and an inode epoch number , a copy-on-write bitmap , and an e-mail reference point.

Those. file versions is a linked list of i-nodes whose head is the latest version of the file. Each of which contains the era number, the copy-on-write bit mask (by the way, cow probably went from here :)) and a link to the next i-node with the next version.

Details on each item:

• era number . The OS stores an epoch counter that corresponds to the current time. when there is a snapshot, the value of this counter is recorded in the i-node, and the counter itself is incremented. those. new era in i-node - file version
• a copy-on-write bitmap . This card is intended to store change marks. Those. the structure here resembles svn-o-like systems - each i-node stores links to file blocks. If the file block has not changed in the current version compared to the previous one - the link to the block is simply copied and two i-nodes point to one block. Links to changed / deleted blocks are stored in i-nodes of old versions. The bitmap also contains checkboxes - whether to copy the link or the block has changed and the link will remain in the old version of the file.
• pointer to the next i-node . Here the developers have proposed a not very beautiful solution. Because in ext3, the chain of i-nodes is limited in length, then we will not be able to continue the chain of file versions forever. It must be said that the meta-information of the directory is also expanded - birthepoch and deathepoch are stored in the links to the i-nodes of the files. It is necessary to keep deleted in new versions, but remaining in the old versions of directories, files. Therefore, the restriction on the length of the chain of i-nodes is circumvented by the following workaround:
  

  If you’re on a line, you’ll end up with a chain of birth epoch entry to a system epoch. It ensures the stability of the new chain. Data blocks may be shared between inodes in the two chains. A long-lived, frequently-updated fi le is described by many short chains rather than a single long chain. While directory entries are also
  linear-search structures, this scheme is by factor. It will improve and it will improve.

Here it is. The structure is quite simple and clear (the author has received a PhD on it).

By use. They say the system is quite stable and can be used right now, although in the current implementation there are a lot of TO-DO and sometimes there is not enough essential functionality ( bugs and todos ). Quote:

Since June 2003, the authors have been running. It is beyond the regulatory framework for which it is designed; for several research projects.

There shouldn't be any problems with speed either - there is a comparative test with ext3 in the documentation, so ext3cow loses by 5-6 ms on two or three types of tests, which is already impressive.

Wait a bit and you can do sections and test. if, of course, such file system functionality is in demand :)

by-the-way. I wonder how the well-known new TimeMachine Apple is implemented. program magazine?

Well, in the end, of course:

The GNU Public License is ext3cow. It is available for download at http://www.ext3cow.com .