This is madness, but since this is a hobby project and not a production server, there is a way:
- Shrink the filesystems on the existing disks to free up as much space as possible, and shrink their partitions.
- Add a new partition to each of the three disks, and make a RAID5 volume from those partitions.
- Move as many files as possible to the new RAID5 volume to free up space in the old filesystems.
- Shrink the old filesystems/partitions again.
- Expand each RAID component partition one at a time by removing it from the array, resizing it into the empty space, and re-adding it to the array, giving plenty of time for the array to rebuild.
- Move files, shrink the old partitions, and expand the new array partitions as many times as needed until all the files are moved.
This could take several days to accomplish, because of the RAID5 rebuild times. The less free space, the more iterations and the longer it will take.
Case-sensitive is easier to implement; it’s just a string of bytes. Case-insensitive requires a lot of code to get right, since it has to interpret symbols that make sense to humans. So, something over wondered about:
That’s not hard for ASCII, but what about Unicode? Is the precomposed ç treated the same lexically and by the API as Latin capital letter c + combining cedilla? Does the OS normalize all of one form to the other? Is ß the same as SS? What about alternate glyphs, like half width or full width forms? Is it i18n-sensitive, so that, say, E and É are treated the same in French localization? Are Katakana and Hiragana characters equivalent?
I dunno, as a long-time Unix and Linux user, I haven’t tried these things, but it seems odd to me to build a set of character equivalences into the filesystem code, unless you’re going to do do all of them. (But then, they’re idiosyncratic and may conflict between languages, like how ö is its letter in the Swedish alphabet.)