From memory, that number is stored as an unsigned 32 bit integer (which can go up to 4,294,967,295) and is stored in GB.
If you have a drive that can survive and have 4.2 billion GB (which can be shortened to "just" 4.2 million TB) of data written to it, its an achievement.
So basically, there is a limit but its so high you will never hit it.
Some can't even handle ISO9660. I was confused why some laptops can't load the Windows 10 ISO dd'ed into a USB, but my desktop could. It worked after changing the USB to FAT32 and splitting the install WIM file because Windows is FAT and exceeded 4GB.
FAT remarkably is still the safest option for general compatibility. If you look at the instructions with BIOS updates by USB on modern MBs there's typically a warning that the USB has to FAT32 formatted.
I've switched a PC from W10 to linux (for the obvious reason) and the issue arises about what should I do with the NTFS formatted data drives. They will work with linux but to remove a point of failure I've backed them up to exFAT formatted external drives and will reinstall to the original drives reformatted to ext4. Probably unnecessary but at least I end up with another set of backups.
Think of it like an odometer. It doesn't specifically track how many times you've washed your car, turned left, or driven down MLK Boulevard at 2am, but if it maxes out and says "999,999 = Critical error = YES" you probably need a new car.
ntfs was added to the Linux kernel a while ago, so they should function fine. No more hacky FUSE workarounds needed anymore.
You should be able to move them to ext4 drives once you are in Linux no problems.
I dual boot, so I keep all my shovel data (movies etc) on NTFS because getting Linux to read NTFS requires clicking, whilst getting windows to read Ext3 would require drilling a hole into hell and summoning Satan.
Reminds me, strong recommendation for QDiskInfo:
Its basically CrystalDiskInfo for Linux.
Makes it really easy to view SMART information for your drives.
ntfs was added to the Linux kernel a while ago, so they should function fine. No more hacky FUSE workarounds needed anymore.
You should be able to move them to ext4 drives once you are in Linux no problems.
I had files failed to write for some reason when a directory was compressed when using kernel NTFS drivers on an external USB drive, but works when using ntfs3g. Good thing I have options.
FAT remarkably is still the safest option for general compatibility. If you look at the instructions with BIOS updates by USB on modern MBs there's typically a warning that the USB has to FAT32 formatted.
I've switched a PC from W10 to linux (for the obvious reason) and the issue arises about what should I do with the NTFS formatted data drives. They will work with linux but to remove a point of failure I've backed them up to exFAT formatted external drives and will reinstall to the original drives reformatted to ext4. Probably unnecessary but at least I end up with another set of backups.
FAT has a single point of failure, the file allocation table. If a single bit goes wonky there, you could lose the entire thing.
I would recommend you use a modern journaling file system for your backup drive, these have redundancies, or even better a COW system with checksumming, since these can actually tell you if a file has become corrupted.
I figured out that the SSD on this Linux system is still being written to at about a rate of 1 MB per minute, constantly. Could "swap space" be responsible for this huge BS?
I haven't seen swap very active though, and the various processes are usually only a few dozens or hundreds of kilobytes at a time. Or maybe it is those processes after all?
I figured out that the SSD on this Linux system is still being written to at about a rate of 1 MB per minute, constantly. Could "swap space" be responsible?
https://github.com/OpenPrinting/cups-sharing/issues/4( a ) -- Here's the issue where the applefags are discussing the sabotage of working printing on Linux. "Yes, use this as an open discussion thread" in 2021, locked as too contentious in 2024.
Thanks. Much of that writing seems to be to "/usr/lib/x86_64-linux-gnu/", but also rarely it is to "/memfd:mozilla-ipc (deleted)" and some firefox folder in "user/lib" also.
(seems System Monitor doesn't track all the writes)
Sounds like you've got a Trannyware package updater going on like packagekitd or something. Nothing should ever write to /usr, save for package updates. It's supposed to be mountable as read-only.
Not "malware", no. packagekitd comes installed by default on typical GNOMEware. I've got packagekitd on the brain because I set my dad up with a Raspberry Pi out at his farmsite and the stupid thing interfered with me updating it last time I was out. I know nothing about your system, not even the files that are being written to, so IDK more than that. Post a full lsof run and I might find something, or I might not.
Thanks. Much of that writing seems to be to "/usr/lib/x86_64-linux-gnu/", but also rarely it is to "/memfd:mozilla-ipc (deleted)" and some firefox folder in "user/lib" also.
(seems System Monitor doesn't track all the writes)
lsof shows you all the files opened by processes, including read-only and file descriptors. It's likely that anything in /usr/lib/ is just the dynamically linked libraries being pulled for their respective programs. MemFD is a file descriptor for memory, it's not an actual file on your hard drive. Linux in general has a lot of files that aren't actually files. Very convenient for scripting, but don't get confused by it.
lsof shows you all the files opened by processes, including read-only and file descriptors. It's likely that anything in /usr/lib/ is just the dynamically linked libraries being pulled for their respective programs.
(just ran systemctl stop packagekit and systemctl disable packagekit BTW)
edit 1: Still chugging away at 1 MB per minute. That's like 2 CDs a day. Even when offline. edit 2: Also, whatever these mysterious writes are, they may not show up in System Monitor. edit 3: And whatever these mysterious writings are, they do not change the available space.
