If I only have a 16G stick what partion sizes would you recomend?
When we create a Virtual Machine we use 10G for everything so it all depends on your priorities.
That depends on how much space you want for data exchange. If you don't need it you can leave out the partition for data exchange.
If you just want a an encrypted Manjaro-To-Go you would want as much space for the root partition as possible.
Technically it is not needed with a 1G partition for /boot - just remember that kernel images takes space and they reside in /boot - you can go as low as 300M for /boot
If we stick to the 5 partition scheme then
- 1M for bios boot
- 50M for EFI
- 4G for data
- 1G for boot
- The rest for the encrypted root
I would recommend one root partition apart from /boot/efi, btrfs with compress=zstd mount option and a DE which is economic on disk space like LXQt instead of KDE.
When the compress option of f2fs is ready I would recommend to try that.
ZFS with LZ4. It compresses the same data faster and better on my system than BTRFS with zstd:10. It shouldn't behave that way and zstd:10 should easily out-compress LZ4.
206G 1.69T /multimedia -- that's one of my zpools. I rsync'd that drive to a 4TB volume, formatted the ZFS drive to BTRFS, mounted it zstd:10, rsync'd the exact same data back and I ran out of space (had half a season of Star Trek Voyager to go...the very last folder before it would have finished). 30GB free or 0MB free. Weird, huh. Like I said, it shouldn't be that way...but real-world and in-theory are two different beasts.
Now - that is interesting - and promising
I have no personal opinion or experience using zfs but it seems some one has a strong opinion
His opinions are always arguable. Now he sees no sense in using zfs, but inclusion of nouveau is ok to him despite the fact that it is responsible for xorg failures and lockups. Developers are strange guys if you ask me.
Yeah, that F2FS one is pretty neat. I'm gonna start using it on my Linux-only USB drives starting with 5.7 or 5.8. If past Linux history is repeated then there'll be some issue with compression when it first comes out. I'm older and more patient now. I'm not gonna just pounce because the kernel is dangling some shiny new F2FS key.
-- quit dangling that shiny key, Linux.
As far as Linus in concerned...this year will the the 5th or 6th year I've been using ZoL. Manjaro includes ZFS support, it performs well, and it does a good job compressing my data. Based on my unfortunate past experiences, my opinion is that ZFS is the safest file system to use that compresses and decompresses data automatically -- the multimedia zpool above is only 5 or 6 years old on a 15 year old drive. That little tidbit should make guessing my first zpool pretty easy.
ZFS is like Manjaro. You can go out and try all the other crap you want, but then you get fed up and go back to what works.
I meant to mention this yesterday, but shouldn't "sgdisk --zap" be mentioned somewhere for the more inexperienced users? I had to do that when trying to write a new GPT table to former, I think it was Fedora Silverblue, live drive the other day.
I wouldn't recommend ZFS for the root part, for home it's maybe the best thing. But won't risk trouble with zfs kernel extramodules.
Manjaro providing the modules makes it one of the safest distributions to use ZFS on root. Probably the only (mainstream) distribution that's safer with ZFS on root is Ubuntu.
Still, consider a broken update, need to chroot. ZFS isn't on the Live USB! One needs an installed rescue system with ZFS to chroot a ZFS system. Am I wrong?
Not at all. I keep one on hand due to how many times I had to downgrade the kernels of my old Arch installations because I missed the pertinent part of the dkms update when I stepped out of the room.
I've never once had that issue on Manjaro, but, then again, I run stable because I'm a ZFS user. IMHO, Manjaro Testing is too close to Arch Stable which is just too iffy to use as an everyday desktop using ZFS user.
How come Manjaro doesn't have a recovery environment included?
I didn't understand that. So, how do you chroot into a ZFS root on Manjaro?
@dalto's ISOs &
zpool import -R /mnt pool_name
edit...and then, for me, there's a boot pool...but it's the same as any other file system outside of using zpool export over umount after that.
Still don't understand exactly, but would at least know what to look for.
What exactly? - And do you know that System Rescue CD since v6 is based on Arch?
Honestly, I'm not sure what would be the best solution.
But my line of thinking is that, AFAIK, Grub is the defacto Manjaro bootloader everyone uses. As long as users have access to Grub then they'd also have access to some sort of minimal recovery environment to fix their main system since "use a Live environment and chroot in and fix /etc/yada and run foobar" is a common fix in the Linux world. By including that in /boot all we'd have to say is "fire up the Manjaro Recovery Environment from Grub and ... ".
The recovery idea came to me because I was reading into Fedora's Silverblue and how it uses a read-only root and how I could do something better with ZFS using a systemd unit to set the readonly option to on or off for certain datasets when necessary...like /usr when pacman is used & /etc for sudoedit or systemctl...so that the only data active in a read/write state, even for root, is as minimal as possible to hopefully prevent corruption.
Where I live there are a lot of thunderstorms that cause plenty of power outages so the idea of a root environment that is, in theory, less susceptible to corruption during a power outage is very appealing.
Then I thought about how they're using an initramfs due to the /usr merge and a few other things they do and wondered if an initramfs would even be necessary if there was a /boot/bin and /boot/lib which expanded into both /boot/bin,lib should also contain a recovery environment and why don't we have one now?
You can read this by @anon58573219
I like some of the ideas in there. Thanks.
You know, there's a lot of great information hidden in the forums here.