Hello Everyone,
We have a fairly important problem that we should try to solve. Let me explain, we use as engine of our system pacs Orthanc (version 1.10), and we would have a great need to be able to manage more than one ‘StorageDirectory’, because when the server has no more space to insert additional disks, we have no way to manage more space without losing the history of the dicom stored on the other disks, because even if I can view the names of patients, I can not view the dicom images because by changing the ‘StorageDirectory’, orthanc does not know where to recover them. Is there a way I can handle this situation?
I had thought of something like that, but Orthanc gives me syntax error…
Caveat: I only run a small Orthanc installation for my personal purposes as a patient, as I described in another topic. That said, I verily believe that from the general “philosophical” perspective it is more logical, especially for a lightweight server like Orthanc, to have storage mechanisms, from logical volumes to all sorts of virtualization, handled by some external storage subsystem, be it the OS tools, or whatever. In that way, the server will be doing what it is supposed to do best, i.e. process and serve to clients information it gets from some storage, which it sees as, well, a (single) logical storage.
I totally agree with you that it should be supported directly by Orthanc. It is clearly in our roadmap and I have actually already implemented a prototype 6 months ago. However, the project was paused because it required a modification of the DB schema we usually try to avoid since it could break some compatibility. I’ll sure get back to it as soon as I can.
Dear Alain,
I am sorry if my comment was not clear enough (although I think it was ), but you seem to say something quite different from what I said. In my view, Orthanc should just see some (single) logical storage as a source of imaging data etc. Something like /home/imaging_data_source. Orthanc should not care about whatever is behind that imaging_data_source, be it logical volumes, physical disks, RAID boxes, shares somewhere in a cloud (on premises or elsewhere), and all sorts of other storage “pieces”. All those should be handled by some storage system(s), which is/are not part of Orthanc and presents/present all those pieces to Orthanc as one imaging_data_source.
I hope now I have explained what I meant.
As far as I’m concerned, I would say that I subscribe to @Maksym_Kozub’s point of view. Orthanc should only deal with one single “logical” storage, and should not deal directly deal with multiple “physical” storages.
From my point of view, multiple storage directories should be implemented as storage area plugin, which is definitely possible using the OrthancPluginRegisterStorageArea2() function in the Orthanc plugin SDK. This is even possible to implement such a feature as a Python plugin.
Sharding between multiple storage directories could be implemented by taking into account the fact that the UUID associated with the attachments are essentially random strings.
I agree with both jodogne and Maksym_Kozub. Orthanc is not natively a system that should support multiple storage systems. IMHO this is down to the administrator to be able to think ahead and put into place an expandable storage system (LVM, NAS, SAN) that Orthanc knows nothing about and simply doesn’t care.
Orthanc does what it does very well, and is very flexible, but IMHO time / effort shouldn’t be spent on taking on underlying storage technology too.
Is this option already implemented in a new version of orthanc?
If so it would help me greatly. I made a mistake in setting the correct clustersize (16KB) on my windows filesystem so my max filesystem size is 64TB and storage wise I now hit my max capacity. I didn’t anticipate growing 20 TB in a year.
Lucky for me I made the mistake on the replica server but now I don’t have a in sync replica.
If you’re using a Linux based storage device, it could be that you can use symbolic links from the original storage device to the new storage device, that shouldn’t be a problem. This would allow you to slowly migrate 00-FF folders from the old storage device to the new. I don’t see why that wouldn’t work,
Here Orthanc is installed on a Windows platform.
I will look into it if the windows feature of symlink (mklink) works as well as on Linux and if Orthanc on Windows can access the directories with mklink.
well, this can work if you don’t need to have all the history already migrated to the new server, but I realize that situations like this should already be prevented
Yes this situation was preventable or at least for now But there will always be a point you will run into the maximum storage/volume capacity. The bigger the storage volumes get the harder backup and recovery will become.
With the older pacs / vna’s I worked with there was always a option to add new volumes and stop data from being written to the old volumes.
Hello Every one, Any update regarding this topic?
I see it is important to handdel the multiple storage Directory, since there are limitation in windows for the size of the volume, and on the other hands I think it will be faster if the data did not exist into one volum only in the long tirm
), but you seem to say something quite different from what I said. In my view, Orthanc should just see some (single) logical storage as a source of imaging data etc. Something like /home/imaging_data_source. Orthanc should not care about whatever is behind that imaging_data_source, be it logical volumes, physical disks, RAID boxes, shares somewhere in a cloud (on premises or elsewhere), and all sorts of other storage “pieces”. All those should be handled by some storage system(s), which is/are not part of Orthanc and presents/present all those pieces to Orthanc as one imaging_data_source.