I have installed my arch onto a SSD with lzo-compression enabled. Now I ran out of disk-space (5GB of 50GB available) and I wanted to change the compression to gzip, which is said to be more effective by means of compression.
Unfortunately, simply changing the corresponding compress=lzo to compress=gzip (or compress=zlib - one finds differents references on the web) results in a not bootable system.
Why is this? Isn't compression a per-file-indication? Or is the corresponding algorithm not included?
I also tried to "recompress" with "sudo btrfs filesystem defragment -czlib" without success....
Any idea how I can manage this process? I don't have an external drive with an appropriate size by hand - so I need to do it on the working system (or via some live-CD)...
In what way is it not bootable? which boot loader are you using? and are you efi or bios? if bios, gpt or mrb?
Edit: does your system get to a bootloader when you try boot with another compression method?, also, what happens if you just omit the compression option, and what is your partition layout?
Last edited by jrussell (2013-10-03 15:31:57)
it boots up until when there is this file check.
Meaning, it overcomes the boot-loader etc. But then, the system is stuck at
systemd-fsck: boot: sauber ....
If I remember right, I was even able to fire up a second terminal via ALT-F2 - but not sure, wether it was functional.
Maybe it's "just" the graphical login manager which doesn't start up?
But after all: Why is there any problem? What is the proper way to undertake such a change?
guntram, please use English on the forum.
systemd-fsck: boot: sauber ....
'sauber' means 'clean'.
I prefer to post output messages as-seen, because sometimes the (homemade) translation is not this straight-forward and may lead to even bigger misunderstandings...
Why in the world are you fscking a btrfs filesystem on boot anyway?! The only thing that the systemd-fsck@.service, systemd-fsck-root.service, or the 'fsck' hook in the initramfs should be doing that would be even remotely reasonable is running a symlink (or copy) of /bin/true and moving on. This is not meant to be run all the time, nor is it recommended.
Your pass lines in your fstab should be zero for every btrfs mountpoint. If your rootfs is btrfs then you should not have the fsck hook in the initramfs.
In order to make this work, you are probably going to have to add another device to the filesystem in order to give it the space it needs in order to handle the tasks you are asking of it. Btrfs is a great filesystem, but things still get a little wonky when you run out of space.
I think you need to go to the btrfs wiki (the actual btrfs wiki, not our wiki page about btrfs) and see what they have to say about running out of space. The other thing they mention is manually going through and making select files have a length of zero with redirection. But if you have snapshots galore, then this poses a unique challenge in trying to actually decrease the amount of used data.
To be honest, if I were in this situation, I would probably just make more space by simply deleting files. But if I really really really thought that changing compression types would help, I would rsync all the data off to an external disk, recreate the filesystem and mount with the compress option, and then rsync it all back. But then again, being a btrfs user, you should have working tested backups anyway, right?
But I really think that your attempts to change the compression type here are simply delaying the inevitable, and this issue of instability with low disk space will come around again in the very near future.
Also, posting output and questions in English is not about your preference, this is a forum rule. You should probably read through that page anyway…
thanks for your extensive reply!
I already deleted most unneccesary user data. As I'm really new to Arch itself, I'm not yet this much into deep linux - especially file systems...
I simply chose btrfs because of this compression option (to go along with the "small" SSD).
I admit to not have read the form rules - usually they are all the same all over the net. But this rule is particulary helpful!
Idea: Why not establish a master rule set (like the "nettiquette" and simply extend this one to the very particular rules for the respective forum? This would narrow them down to two or three, which would be read by everyone, then...
Thanks a lot - I'll try to survive with the situation!