Pdumpfs - a cool versioning utility, Elephant Filesystem

Here is a simple versioning utility - for those who like to keep it short and simple. pdumpfs is similar to Plan9’s dumpfs. pdumpfs is written in Ruby and stores snapshots in YYYY/MM/DD format. To the current snapshot, only those files are copied which actually have been modified. Those which haven’t been modified end up as hardlinks to the previous snapshot. Cool ain’t it ? Have a look at pdumpfs at http://0xcc.net/pdumpfs/index.html.en. Enjoy !

I came across a pretty interesting filesystem called the Elephant FileSystem. Why ? Because Elephants never forget ! EFS was made keeping the public in mind. Thats right ! EFS is what I call cool. Let me explain. Manually controlled versioning filesystems need to be controlled ( excuse the redundancy ). This can result in too many backups and not to mention the confusion that follows. Apart from this, lets just say you are working on a file and make a blooper ( read as edit a whole paragraph and save only to realize that the previous paragraph was better ) and did not run the versioning utility before undertaking this enterprise, you have to resort to your memory. EFS versions a file as soon as it is written to. However, most operations are reversible. Deleting a file does not mean that it has been booted out of the storage device. Data retention policies can be specified for every file or a group of files. EFS scores all its brownie points courtesy its understanding how users store files on their drive. While it becomes impossible to remember what distinguishes a version of a file from another, EFS does it using the concept of landmark files. This is because storage is always limited. One can never have an infinitely large storage device. When you get close to occupying all the space on your drive, it becomes necessary to kick out a few of those versions. EFS’s creators believe that a landmark file should be allowed to stay and other lesser important files be removed. Heuristics of files should of course be determined by us. A landmark could be newest version of the file or one which had the largest time gap between successive versions and so on. It is also important to distinguish between source files and object files as object files are rarely of use after linking The paper talks of two versioning policies - keep one (the policy that comes with all filesystems)/ keep all (the policy that comes by default with most versioning filesystems ) and keep landmarks (the coolest of the policies ). The filesystems we use on a day to day basis allow us to link one inode per file. Thus one can use the inode number to name files. However EFS departs from this model as files have multiple inodes. It redefines inode numbers to index a file’s log instead of its inode.

EFS treats directories differently compared to files. The directories plainly store versioning information. The creation and deletion (if deleted) times of a file are stored. Directory entries are retained as long as at one version of the file they name is retained.

EFS is cool but I do feel that a nomenclature style like ext3-cow would really be excellent. Have a look at EFS, its definitely worth it .