It reminds me of when in the early 2000's I had bought an sgi off ebay and was scouring the local computer repair shops for cheap 80-pin scsi drives. which were understandably a bit rare in my rural area. I I took a chance on one cheap drive, I think he said it came out of some sort of ibm array, but it ended up having 510 byte sectors, Which is persona non grata in any reasonable system. And after a lot of reading the docs(sgi had some great docs) I determined the only thing to try was a low-level format. By this point ide drives had lost the ability to low level format but scsi drives were still able to do it. And after a few tense hours, the docs warn that if it failed or the parameters were wrong the drive would probably be bricked. it worked! and served quite a few happy years in my O2.
One my favorite things I found in the SGI docs was instructions on how, for the highest speed xfs array you should set it up, one drive per scsi controller then stripe it. An arrangement I found exotically extravagant.
Even better. Discreet (later acquired by ADSK) used to ship proprietary RAID arrays for use on SGIs with their high-end editing systems. They had this smart thing where frames of larger sizes would be placed on the outer tracks of the platter for faster reading/writing - one of their promises was "if you press play, it plays" - and it always did uncompressed. What they did is a custom filesystem ("stonefs") that you had to use, the disks would not be formatted with xfs but instead with that proprietary filesystem. Now here is the tasty bit: the replacement hard drives they would provide themselves as well. Apparently, the "proprietarization" of a disk for such an array involved overwriting a few sectors of the disk with custom magic bytes so that the stonefs formatting software would accept it as "native". Obviously when disks in arrays would die, and the array would be too old to support, those disks would become unobtainable. I knew (via via) of a guy who could "flash" an off-the-shelf disk with the magic bytes so that it be recognized as a proprietary stonefs disk.
Luckily they developed a system for frame-addressable storage on standard filesystems in parallel, and when they decided to step off the "proprietary hardware" story all they had to do was enable it. Now it's just a directory structure.
I knew you could reformat NVMe drives to have 4096 byte instead of 512 byte logical sectors, but didn't know there was a standard command to also do that for non-NVMe drives. I might try that next time I get a new non-NVMe SSD.
Same here. Coincidentally I just upgraded from 8 GB to 32 GB and this was the first time my new RAM was full. FF ate 30 GB! :-)
I also didn't saw the memory usage in process manager, only in Windows Task Manager. Also interesting: Closing the tab did not release the memory, the process keeps eating more RAM until I kill it. By the way, I'm using FF 115.14.0esr.
One my favorite things I found in the SGI docs was instructions on how, for the highest speed xfs array you should set it up, one drive per scsi controller then stripe it. An arrangement I found exotically extravagant.