However, Linus Torvalds, the head of Linux, was very unhappy with this application, and his beef was not with the package pull request, but with the GitHub merge commit. The Paragon “NTFS3” kernel driver provides better read/write support for Microsoft’s NTFS file system than other kernels or the FUSE option for supporting this file system on Linux. It is understood that after several revisions, Paragon submitted a pull request a few days ago for its NTFS read/write driver, dubbed NTFS3, for the upcoming Linux 5.15 kernel. I'm not a dev, so I'm sure it's easier said than done.In August 2020, Paragon, a company working on a variety of storage technologies, made a high profile announcement that their NTFS read/write driver would be in mainline development in the Linux kernel, after years of being available as a commercial driver for those who need reliable support for Microsoft file systems on Linux. I would rather there be healthier memory management without crippling REFS optimizations. With private rix refs.sys, and registry tweaks enabled, and RAM increased to 64 GB, the delete storm finished and climaxed at 44GB RAM used, then fell back to normal expected levels. We have an 18 TB repo, and had only 16GB ram. Only by quadrupling our RAM on the repo, with the registry tweaks in place, were we able to get the delete storm to finish. In the end, none of the registry tweaks fixed our issue. However, these registry changes disable certain optimizations that REFS provides, and could heavily affect the performance of REFS that we have come to appreciate. Prior to increasing ram on our repo, MS had us test a plethora of registry changes, some of which haven't been mentioned in this forum. However, there is no check to ensure that all available RAM is not used up, and has caused our repo to lock. In our case with the REFS deletes (they called this a delete storm), the process of flushing the metadata to disk cannot keep up, so the driver queues the metadata writes in RAM so as not to slow down the process. If you have enough RAM to spare, go REFS, but follow the best practice guide. MS Dev suggested to us 10GB ram for every 1TB of space used in the REFS repo. We are about to implement 2 x 150TB usable disk RAID60 repos for about 1000 VM backups. Should we go with REFS and disable block clones (does this work?) to be prepared for the fix or should we go with NTFS. Next week, we are about to create our new Veeam Backup Repos. RAM usage is increasing so I will have to keep an eye on it. Once that was done I reformatted the disk to 64K block size and have removed the repo from the scaleout pool and dedicated it to the 50TB VM. This appear to stabilise the memory usage (again could be coincidence) and I got all the data off. "RefsNumberOfChunksToTrim"=dword:00000080 I stopped the file copy and applied the following key. I was then able to start copying off all the data without further issues but the RAM usage jumped up very quickly. I hard rebooted and remove all refs key and applied the above key. However, it become unresponsive very quickly. I then started to copy off a small number of VM backups that were also on the repo. On a different server I removed a 50TB (yeah not a good idea we have no choice) single VM backup in an attempt to change the block size from 4k to 64k - I agree it probably isn't right but has performed adequately for 6 months. However, last night it didn't lockup and appears more stable and all backups have worked. I've artificially filled the disk to stop Veeam using it and will slowly move data off. This seems to have stabilised the server concerned and I was then able to start moving backup data off - this could be coincidence. "RefsEnableLargeWorkingSetTrim"=dword:00000001 In sheer desperation (because I couldn't copy the data off) I've hardreset (because it was locked up) quickly removed all the REFS keys then applied I attempted to get some of the data off one of the server and experience further hangs. Just to confirm, you've seen complete hangs shortly after / during boot?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |