Welcome to the community @Dushyant_Bangal!
Btrfs is not widely used or tested with MongoDB. An important consideration is that by default Btrfs is a Copy On Write (COW) filesystem which will not be ideal for use cases with frequently updated data files (for example, databases and VMs). Fragmentation can lead to significant storage wear which will reduce the lifespan of your storage device.
As mentioned on the Btrfs Gotchas wiki page:
Files with a lot of random writes can become heavily fragmented (10000+ extents) causing thrashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM
The consequences of write activity over time are difficult to predict, but you could try simulating your predicted workload. It sounds like you may be planning for an insert-only workload, which should be less problematic for Btrfs than a workload including updates and deletes.
If you do plan on using Btrfs, I would definitely look into tuning Btrfs mount options for the volume hosting your MongoDB
storage.dbPath (for example, possibly using the
nodatacow option for a workload involving updates & deletes). Btrfs also has some features like checksums and compression which duplicate work performed in MongoDB’s WiredTiger storage engine by default, so if performance is a consideration you probably don’t want to have overlapping features enabled.
It would be excellent if you can share any Btrfs experience with the community so there is more information on what does (or doesn’t) work well with MongoDB. Btrfs tuning experience for other databases should also be relevant.
For a production environment I would strongly recommend using XFS for the broadest experience and support. You can use LVM (Logical Volume Manager) with XFS for more operational flexibility, including creating logical volumes spanning multiple physical disks and taking consistent snapshots.