111–120 of 141 posts
Earlier quoted context omitted.
Some filesystems can be unable to delete a file if full. Something to be a bit worried about.
Instead of deleting the ballast file you can just truncate it. That works on ZFS when you fill the pool and delete starts failing.
Earlier quoted context omitted.
Also if you VMs on a disk backed by ZFS it's trivial to extend those disks provided you actually do have space on the real disk. (Even automatic with LXC).
Please explain!
I use Proxmox as the hypervisor, and the ZFS resize part is supported on the GUI and it's trivial to use. Let me know if you need more details.
A neat trick I was told is to always have ballast files on your systems. Just a few GiB of zeros that you can delete in cases like this. This won't fix the problem, but will buy you time and free space for stuff like lock files so you can get a working system.
Better fill those files with random bytes, to ensure the filesystem doesn’t apply some “I don’t actually have to store all-zero blocks” sparse-file optimization. To my knowledge no non-compressing file system currently does this, but who knows about the future.
A neat trick I was told is to always have ballast files on your systems. Just a few GiB of zeros that you can delete in cases like this. This won't fix the problem, but will buy you time and free space for stuff like lock files so you can get a working system.
This is why I never empty the Rubbish Bin/trash Can on my Linux laptop until the disk fills.
Earlier quoted context omitted.
Not needed. All your unused/unfilled space is that space for wear-leveling. It wasn't needed even back then besides some corner cases. And most importantly 10% of the drive in ~2010 were 6-12GB, nowadays it's 50-100GB at least.
Empty space is good for wear-leveling but enforcing a few percent extra helps. > And most importantly 10% of the drive in ~2010 were 6-12GB, nowadays it's 50-100GB at least. Back then you were paying about $2 per gigabyte. Right now SSDs are 1/15th as expensive. If we use the prices from last year they're 1/30th, and if we also factor in inflation it's around 1/50th. So while I would say to use a lower percentage as…
Only if you fill the drive up to 95-99% and do this often. Otherwise it's just a cargo-cult.
> So while I would say to use a lower percentage as space increases
If your drive is over-provisioned (eg 960GB instead of 1024GB) then it's not needed. If not and you fill your drive to the full and just want to be sure then you need the size of the biggest write you would do plus some leeway, eg if you often write 20GB video files for whatever reason then 30-40GB would be more than enough. Leaving 100GB of 1TB drive is like buying a sneakers but not wearing them because they would wear.
Earlier quoted context omitted.
This trick is actually used by some banking apps. They fill app their mobile apps with junk data just to make the APK/IPA bigger. So if they need to push an urgent update, they won't have users that can't update because their phones are full to the brim. I know two Italian banks that do it, Unicredit and Intesa. The latter was on the news when a user found out that one of the filler files was a burp recording [1]. [1…
Doesnt this create an arms race situation where every 'critical' app claims a larger diskspace than necessary, just in case, and accelerates the issue?
Earlier quoted context omitted.
This trick is actually used by some banking apps. They fill app their mobile apps with junk data just to make the APK/IPA bigger. So if they need to push an urgent update, they won't have users that can't update because their phones are full to the brim. I know two Italian banks that do it, Unicredit and Intesa. The latter was on the news when a user found out that one of the filler files was a burp recording [1]. [1…
Interesting, makes sense, seems to be bad precedent if everyone follows suit.
A neat trick I was told is to always have ballast files on your systems. Just a few GiB of zeros that you can delete in cases like this. This won't fix the problem, but will buy you time and free space for stuff like lock files so you can get a working system.
This is my snippet i used alot. In doubt when even rm wont work just reboot. Disc Space Insurance File fallocate -l 8G /tmp/DELETE_IF_OUT_OF_SPACE.img https://gist.github.com/klaushardt/9a5f6b0b078d28a23fd968f75...
Earlier quoted context omitted.
Similarly, I always leave some space unallocated on LMV volume groups. It means that I can temporarily expand a volume easily if needed. It also serves to leave some space unused to help out the wear-levelling on the SSDs on which the RAID array that is the PV¹ for LVM. I'm, not 100% sure this is needed any more² but I've not looked into that sufficiently so until I do I'll keep the habit. -------- [1] if there are m…
Not needed. All your unused/unfilled space is that space for wear-leveling. It wasn't needed even back then besides some corner cases. And most importantly 10% of the drive in ~2010 were 6-12GB, nowadays it's 50-100GB at least.
In fact since enlarging live ext* filesystems has been very reliable² for quite some time and is quick, I tend to leave a lot of space initially and grow volumes as needed. There used to be a potential problem with that in fragmenting filesystems over the breadth of a traditional drive's head seek meaning slower performance, but the amount of difference is barely detectable in almost all cases³ and with solid state drives this is even more a non-issue.
> And most importantly 10% […] nowadays it's 50-100GB at least.
It doesn't have to be 10%. And the space isn't lost: it can be quickly brought into service when needed, that is the point, and if there is more than one volume in the group then I'm not allocating space separately to every filesystem as would be needed with the files approach. It is all relative. My /home at home isn't nearly 50GB in total⁴, nor is / anywhere I'm responsible for even if /var/log and friends are kept in the same filesystem, but if I'm close to as little as 50GB free on a volume hosting media files then I consider it very full, and I either need to cull some content or think about enlarging the volume, or the whole array if there isn't much slack space available, very soon.
--------
[1] The root-only-reserved blocks on ext* filesystems, though that doesn't help if a root process has overrun, or files as already mentioned above.
[2] Reducing them is still a process I'd handle with care, it can be resource intensive, has to move a lot more around so there is more that could go wrong, and I've just not done it enough to be as comfortable with the process as I am with enlarging.
[3] You'd have to work hard to spread things far and randomly enough to make a significant difference.
[4] though it might be if I wasn't storing 3d print files on the media array instead of in /home
Earlier quoted context omitted.
If the alarm works. And it actioned not just snoozed too much or just dismissed entirely. Defence in depth is a good idea: proper alarms, and a secondary measure in case they don't have the intended effect.
Surely there are pitfalls either way. A ballast file can be deleted too readily, or someone could forget to re-add it.