> After freeing the new SATA SSD, I also filled it with butter. Yes, all the way, no GPT, no MBR, just Btrfs, whose subvolumes were used in place of partitions I would not recommend doing that. It might work for now, but there's a high risk of the disk being seen as "empty" (since it has no partition table) by some tool (or even parts of the motherboard firmware), which could lead to data loss. Having an MBR, either…
Neat! I went looking for ways to create a protective MBR, learned a lot from the Gentoo wiki, some interesting info about how Windows does things in the link below, but the way to achieve this seem to be to just format the disk as GPT and then truncate it to the MBR (or just use one big GPT partition). https://thestarman.pcministry.com/asm/mbr/GPT.htm
NixOS on Btrfs+tmpfs
51–55 of 55 posts
Re: NixOS on Btrfs+tmpfs
#52Earlier quoted context omitted.
Neat! I went looking for ways to create a protective MBR, learned a lot from the Gentoo wiki, some interesting info about how Windows does things in the link below, but the way to achieve this seem to be to just format the disk as GPT and then truncate it to the MBR (or just use one big GPT partition). https://thestarman.pcministry.com/asm/mbr/GPT.htm
I would also not recommend formatting the disk as GPT and "truncating it to the protective MBR". Not only there's a good chance of the GPT re-appearing on its own, either because some software noticed it was corrupted and copied it from the backup copy at the end of the disk, or because some software noticed it was missing and created a new one, but also there's a chance of it once again being treated as if the whole…
Re: NixOS on Btrfs+tmpfs
#53Earlier quoted context omitted.
>In the ordinary cases, btrfs full behavior is the same as other filesystems. Exactly that's NOT the case: >>-Reboot and end up with unbootable / You can test it for yourself, it "works" reliable since over more then 8 years.
I just tried it like I mentioned in another comment in this thread and cannot reproduce it. As much effort as you've spent complaining about this problem in this thread you could have provided a proper bug report in the proper venue. It's not going to get fixed by complaining on HN. So I have to ask if you just want to complain about it or if you want it fixed? Both can be true and legit. But it still requires a repo…
You don't even tryed....a loop device really? And hey i use zfs, i don't trust btrfs who has problems (data-loss) since 10 year. No thanks....hell even SLES recommends for data partitions XFS.
>But it still requires a report in the proper venue with enough detail for someone else to reproduce.
Hey how about you? Since you seam to care..install a vm ~10minutes? fill it ~10minutes? there you go.
Re: NixOS on Btrfs+tmpfs
#54Earlier quoted context omitted.
Ah, so it's a special btrfs feature, as root you can kill your filesystem by simply writing a file to it. I wonder what function that serves. But hey how about a quota behind the scenes?....you know like ZFS? AFS? ReFS?...you know so the filesystem tells the user "sorry cant take anymore" before it really cant take anymore? That would be some crazy enterprise level stuff.... You know, a Filesystem that immediately st…
This can happen on any filesystem under the circumstances of it becoming full as root. You are misinformed if you believe such isn't the case. "Can't boot" is also vague. I've had data loss with XFS in 2002 or so (didn't have backups), couldn't mount filesystem anymore. Thanks to help on IRC from devs I got almost all data back. I've been able to get recover data from a dying Deathstar, too. And then there's the RAID…
No true with ZFS and XFS, you are trying to defend a ill designed filesystem....in typical linux *fashion ;)
It's S#it but at least we "invented" it.
Re: NixOS on Btrfs+tmpfs
#55Earlier quoted context omitted.
>So if you're able to trivially reproduce it, Make a VM OpenSUSE or Fedora (tested just these two) fill it and see it not boot anymore...it is trivial.
OK this is a very different scenario than what I thought you were talking about (a broken file system). If a file system is full such that writes aren't possible, boot can fail no matter the file system. This isn't a file system problem. It's a failure to manage space. Most distros require a read-write /sysroot, and expect the ability to write to disk. If they can't write, various services will fail and that can prev…
Please read my comment in full especially that point:
- rm blabla && sync
- reboot