I am trying to understand what are file level snapshosts. Anyone has idea as to which filesystems supports this so that I can try it out.
First off, welcome and thank you for your interest in contributing to an open source project. I'm not sure if you've already seen https://ceph.com/irc/ and https://ceph.com/contribute/ but if not, contacting the Ceph project is probably a good place to start.
The description there is fairly sparse, but they do say what the use case is: Dropbox-style versioning. Dropbox (which is, unfortunately, not free software) keeps old copies of files you upload to it. So if you edit a file and make a mistake, you can get the pre-mistake version back. It's similar to source code version control, except Dropbox automatically commits, it's not something you do manually.
btrfs has a similar feature, implemented by taking quick, cheap snapshots on a per-subvolume level (a sub-volume can be a single directory). Snapshots share data and only blocks that are modified become unshared (aka copy-on-write). Snapper, which I confess I've never used, is a user-friendly tool built on top of this. Reflink (which that bug blocks) is a similar feature on btrfs which allows making a copy-on-write copy of a single file.
Pretty much any other filesystem with snapshots should provide a similar feature, I believe ZFS does as well, for example.
I don't know Ceph internals at all, but a word of warning — that bug may well be a very significant undertaking. There is potentially a lot of work not just in making sure writes perform the copy as needed but also in keeping it at all efficient; you don't want e.g., rewriting a 4GB file to wind up with a million 4K blocks of it fragmented across the entire device.
'File versioning' is the more common term for what that Ceph issue is talking about. The File History feature in Windows 10 and the versioning feature in Dropbox are good examples you've probably encountered before (though neither of them is done by the filesystem).
As far as filesystems that actually implement this:
- Files-11: The classic Vax/VMS and OpenVMS filesystem. File versioning was an integral part of the design of VMS, so it's only natural that the main filesystem it used supported it natively. When versioning was enabled, you could access old versions of files by using a special syntax for the file path.
- Fossil: The main filesystem of Plan 9 from Bell Labs after 200. Just like files-11, fossil was designed for versioning from the start, though how you access old versions is somewhat different from files-11. Fossil had the additional feature that it could push out old versions to external storage systems (usually running Venti, an archival WORM-style filesystem). The original filesystem for Plan 9 also supported versioning, and similarly could push data out to archival storage, but it fell out of use pretty quickly when Fossil became widely available.
- GitFS: GitFS is a special FUSE-based interface for the git version control system. It lets you mount a git repository like a local filesystem, and automatically commits any changes you make. I've seen similar projects for other VCS software too. Official repository is here.
Those are the only three I know of personally. I think there are some distributed filesystems that support this too, but I've not got as much experience with that.
Also, it's worth noting that neither BTRFS nor ZFS actually support this. Both of them do have snapshotting support, but they can't snapshot individual files (snapshots on both operate at a higher granularity). Both of them support reflinks though, which means you could implement this functionality on top of them, it's just not something they do natively (OCFS2 and XFS also support reflinks).