The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Is there a limit to how much it can keep track of? Like how many writes and TBW can it count before crapping out?
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.
 
Is there a limit to how much it can keep track of? Like how many writes and TBW can it count before crapping out?
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.
 
Last edited:
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.
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'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
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.

Edit: Or worse, Richard Stallman.

If it works, don't fuck it.
 
Last edited:
Reminds me, strong recommendation for QDiskInfo:
1750578500014.webp
Its basically CrystalDiskInfo for Linux.
Makes it really easy to view SMART information for your drives.
 
Last edited:
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?
 
Last edited:
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?
Use lsof and drill down.

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.
 
Last edited:
Use lsof and drill down.
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)
 
Much of the writing seems to be to "/usr/lib/x86_64-linux-gnu/"
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.
Yeah, I presupposed he'd know more about lsof than that, given his explanations. Good point. lsof lists reads and writes ("ls" "o"pen "f"ile).
 
Post a full lsof run and I might find something, or I might not.
I don't want to post a full run now, but here's samples of recurring patterns:

[deleted, see post further down:]

Thanks. So looks like the biggest offender is some kind of logging, with "systemd-jornald" and "rsyslogd"...

There's also "jbd2" doing some constant writing, though not as much. So what's this BS and how do I stop it?
(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.
 
Last edited:
Back
Top Bottom