I recently upgraded my media server to a 64 bit OS, and also increased the RAM to 4GB (the most the aging mobo will support.)
An area where disParity can benefit from 64 bits and the extra virtual memory available is the temp file it generates while processing a file. In order to minimize the risk of parity corruption due to an unexpected failure, parity changes due to an add or delete are written to a temp file first, and then flushed to the parity set after the add or delete is finished. For small files (typically less than 1GB) disParity currently uses a memory buffer for this temp file, but for larger files, it has no choice but to write it to disk, and then read it back from disk and write it to parity, which significantly slows down parity updates for large files.
I've tinkered with the code a bit, and tried switching the "memory buffer" implementation to one using memory mapped files instead. It seems to provide a dramatic improvement to parity updates for the cases where it would have previously used an on-disk temp file.
Is this something any current disParity users on 64 bit out there would find useful? There are a couple of drawbacks I know of:
1) The change requires updating to version 4 of the .NET runtime, which is where MS added support for memory mapped files. Not a huge deal, but I liked the fact that previously disPariity only required version 2, which just about everyone has these days.
2) It's hard for disParity to know how big a memory mapped file it can get away with. This is a function of the amount of RAM in the machine and how much of it is currently available for the file. If disParity tries to create a memory mapped file that is too large, it will work, but system performance slows to an absolute crawl. Ultimately, the "max" size for the temp file is something that the user will have to tune, which is not very user friendly, unless I can come up with some other way to figure this out automatically.
-Roland