Take the time to analyse this post on Anna's Archive
They teach you in meticulous detail why they took the time to create mirror backups of this musical archive which is torrented in bulk at 300 TiB
#HDD #EXT4 #partitions #Linux #technology #InfoSec #passwords #Spotify #breach #300TB
It may look like I was joking but making such a backup is technically simple.
300TiB / 24TiB per HDD is 12.5 drives
300TiB / 16TiB is 18.75 drives
In reality it's more complex.
A 16TiB HDD is not 16TiB but 16TB lineair
Given a typical 4TB HDD I get just 3.64TiB in partitoned EXT4 HDD Space
That is 91% of the 4TB HDD
At 16TB that is 14.56 TiB {yes the loss is enormous and those hard drive companies are idiots because computer systems count in base² Binary not base10}
A 16TB drive is actually a 14.56 TiB Drive, it should be sold as 14.56 TiB not 16TB because that is misleading and false advertisement.
With these parameters we will need in reality 300 TiB / 14.56 TiB = 20.6
So we will need 21 drives for the task at 14.56 TiB. In the replication you will need twice the amount
This would become a JBOD just a bundle of drives, which is the easiest form to concatenate hard drive space to together.
A 4U JBOD enclosure can harbour a lot of drives. At the most you will need two.
Double the amount if you want a local backup of your main Spotify data.
Then you will need a 1U case for the computing System. A typical server motherboard, 1x AMD EPYC CPU, 512GB ram is more than sufficient.
You will need Fast Access to the Drive Array. 10GBit / sec in duplo should be enough. That means that your switches cables and network infrastructure will be expensive.
The high cost of AC power globally, can be a limiting factor when you have to power 42 hard drives provided that you are a Soho Network Builder, though.
That is the only factor you cannot calculate with constants
^Z
#HDD #EXT4 #partitions #Linux #technology #InfoSec #passwords #Spotify #breach #300TB
External disk with ext4 doesn’t auto-mount
Full post here. https://rene.seindal.dk/2025/12/08/external-disk-with-ext4-doesnt-auto-mount/
I have an external SSD in a NVME USB enclosure, with an EXT4 file-system. When I plug it in, it doesn't auto-mount, and haven't done so for a while.
Most other external disks do auto-mount.
I finally figured out why, and how to fix it.
🐧 Linux 6.19 porta nuove migliorie a EXT4:
- Deframmentazione online più efficiente grazie all’uso dei folios
- Supporto a block size > page size, seguendo l’approccio già visto in Btrfs
- Caching ottimizzato per inode senza ACL POSIX
- Documentazione aggiornata e gestione più chiara dei codici di errore
https://www.phoronix.com/news/Linux-6.19-EXT4
#Linux #EXT4 #Kernel #OpenSource #Performance #SysAdmin #DevOps #Innovation
@borgbackup on IRC I also got the suggestion to make a backup with "--files-cache=disabled" and then diff with that. I'll keep that in mind for next time I have a partial disk / filesystem failure/hiccup. I think diff'ing and manually sifting through between now and half a year ago would be a bit much.
But as I didn't experience/notice any file corruption and I would assume that corruption risk would be minimal with a journaling FS like #ext4 anyway, I think/hope I'm good now.
For half a year now I had stopped the "borg prune" with @borgbackup. Because back then my #ext4 had a hiccup (maybe caused by a #ZFS crash / kernel panic...), it had a broken journal leading to some files in /lost+found/. Thanks to "borg diff" I could now get an overview of what changed in my home directory. And that looks fine. So started "borg prune" now.
It will be nice to get feedback from people who work in small to medium scale storage systems. I want to learn efficiënt ways to improve upon my archival storage procedures on a femto scale budget
^Z
#OpenSource #Photography #DSLR #SLR #camera #storage #technology #tar #tape #HDD #SSD #EXT4 #ZFS #HAMMER2 #RAID
There's one subject I haven't seen photographers talk about
The subject of photo archive management
It's not as easy as you may think.
Many people, especially in this last decade, grab an Android, grab a toy camera, as I call the small yet much handier cameras from camera brands like Fuji Nikon and Canon then point at the scene, often don't even know what the difference is between proper lighting and inverse lighting, then shoot their photograph.
Most end users don't even realize that they need an infrastructure to properly archive their photographs whatever the quality maybe.
The last time I lost data was in the floppy disk years; after that I never lost anything I archived on magnetic 🧲 media.
That case was a dirty read write head on a floppy drive which scratched my master and my backup disc on surface one.
I mitigated that error by using two floppy drives. One FDD specifically for the master disc after I cleaned the heads, one drive specifically for the backup disc after I cleaned those heads.
In the harddisk era I never lost any data. I use tried and tested procedures which are documented in request for comments RFC. You will find many, just search for them. Even those using tar -cvfz are good
At a certain point in time I switched from film to DSLR. The question was immediate
With my negatives I print what I need and since film 🎥 lasts {almost} forever I had no backup issues since everything was analog.
My first digital DSLR body comes with two SD card slots. 8 GB per slot giving me 16 GB of storage. I usually shoot one card full then go to the other. I use my analog method of shooting only proper scenes. I don't use the camera as a machine gun and then sort out through all the mess which photographs are fair. Quality above quantity. I have a couple of hard drives where i stored the backups and the data Is never Lost. Sounds easy right?
When another DSLR or Point & Shoot body comes in the mix you know need to manage the backups of two devices. Another point and shoot comes in the mix and another DSLR comes in the mix.
Backing up all these devices to the hard drives that I use is risky if one drive fails. The file system I use is EXT4 a tried and tested stable file system.
I mitigated that problem by doubling the amount of hard drives. Now the amount of hard drives start to grow in such a manner that they do not fit in one case anymore. That means another machine had to be built to spread the amount of hard drives. There are significant costs, you need a motherboard a processor, memory, video output, a power supply, another case and you need to pay for electricity to power the new system.
You're starting to see the pattern and the risks involved when you don't want to lose data. When Android phones started to come in the mix it became really interesting.
You can use your Google account to store the images but you'll soon realize that even though they seem to give you a lot of space photographs fill it up exponentially fast.
Also you're storing it on somebody else's computer, who will abuse your data.
There has never been, there shall never be any cloud.
Soon you're faced with the fact that you need a network attached storage system NAS, where you can add drives and still use at the most two or three of those systems to manage your photographic data.
Without realizing it you've become a librarian, without the proper training and study which takes about 2 years!
If you have the computing & Database experience like me, it is easy to set up a plan to do proper archival storage.
The proper plan can include ZFS as a file system, which you will run natively in freeBSD or any other flavor. You can also choose HAMMER2 as your file system running in DragonFlyBSD, which has a very light footprint and a massive robustness built in, just like ZFS
For most people the financial factor will be a bottleneck, when you need to manage eight to twelve to even twenty-four camera devices, when you have stored photographs digitally for decades, starting from the beginning of DSLR camera bodies.
^Z
#OpenSource #Photography #DSLR #SLR #camera #storage #technology #tar #tape #HDD #SSD #EXT4 #ZFS #HAMMER2 #RAID
Which local file systems does macOS 26 support?
For some reason and it wasn't installed on my Debian based MX Linux distro.
I've just installed sysstat, the package it comes in, and I have to Thank you for pointing me to the program
#IOstat #USB #USB3 #USB2 #technology #filesystem #ext4 #thumb #drive
I remember that command from Linux and I've just checked online since I'm on the phone and found this hit
I didn't see that specific switch though
https://www.man7.org/linux/man-pages/man1/iostat.1.html
#USB #USB3 #USB2 #technology #filesystem #ext4 #thumb #drive
Up to now I have not seen any USB thumb drive which can write as fast as it reads in practicality
The 64 to 256 GB thumb drives that I work with, write at about 6 to 8 Mbps when they are in sync mode
In the beginning the drive seems to lie and shows speeds that are close to the absolute speed of the USB 3 Connection. In reality is not really a lie because the Linux Operating System loves to cache it's file systems, especially if they're native, like ext4
However the file system warns you never to remove the thumb drive until it's actually done writing. If you use something like Midnight Commander it will show you that the writing speed drops all the way down to six to eight megabytes a second!
That happens on both modern systems and on Old obsolete systems with just USB 2
#USB #USB3 #USB2 #technology #filesystem #ext4 #thumb #drive
#Bcachefs is a next-generation #Linux #filesystem
petit sondage pour se détendre le week-end
Hop je vous propose un petit sondage de la plus grande importance pour m’aider à faire un choix qui va bouleverser ma vie. :3
Z’êtes prêt.e ? Vous aurez 2 choix à chaque fois. :3
Hop je vous propose un petit sondage de la plus grande importance pour m’aider à faire un choix qui va bouleverser ma vie. :3
Z’êtes prêt.e ? Vous aurez 2 choix à chaque fois. :3
