Live data from Hacker News

NixOS on Btrfs+tmpfs

cnx.srht.site

51–55 of 55 posts

Re: NixOS on Btrfs+tmpfs

#51
post #44

> 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

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 disk was empty (since the "protective MBR" says it's a GPT disk, and the GPT has no entries). If you want to have just the single MBR sector, then create a traditional MBR with a single partition spanning the whole disk instead of a GPT "protective MBR". But that will not gain much, since you should align your partitions (IIRC, usually to multiples of 1 megabyte) for performance and reliability reasons (not as important on an HDD, where you can align to just 4096 bytes or even 512 bytes depending on the HDD model, but very important on an SSD), and the space "wasted" by that alignment is more than enough to fit the GPT.

Re: NixOS on Btrfs+tmpfs

#52
post #51

Earlier 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…

Ah, I missed there was a unique label indication GPT was involved in the protective MBR; I I'd read it, it essentially is just an MBR with a single max-size entry, and I didn't consider there might be anything else; and ofc, it is a bit of a pointless thought experiment. Thanks for sharing!

Re: NixOS on Btrfs+tmpfs

#53
post #41
post #38

Earlier 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…

>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.

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

#54
post #48
post #32

Earlier 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…

> 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.

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

#55
post #46
post #39

Earlier 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…

>You are saying it won't boot but that's not at all a case of a broken file system

Please read my comment in full especially that point:

- rm blabla && sync

- reboot

Post reply on HN