[Fnoord]

A lot of consumer grade SSDs and flash (microSD, eMMC) don't like it when they are near full. That's why you should set a reserved space and quotas. Notice your dd trick requires root which ignores the reserved space. At some point, its PEBCAK.

[vladvasiliu]

> A lot of consumer grade SSDs and flash (microSD, eMMC) don't like it when they are near full

I've heard about this, but my understanding was that when this happens, performance becomes extremely poor. While that may be quite bad, it's still worlds apart from losing data.

There's also the fact that the user may have partitioned the drive in a such a way to prevent it from ever filling up. Even root can't fill the partition beyond its size. Here, you have to go out of your way to make sure the partition doesn't fill out, or else you have a bad time. Shit happens, so this does look like a FS bug to me, much more than PEBCAK.

[Fnoord]

> While that may be quite bad, it's still worlds apart from losing data.

Except if you keep overwriting a flash-based storage system, at some point that flash storage gets destroyed (wear level). You can absolutely achieve such by having a near full filesystem on flash. Mechanical harddrives or partitions don't suffer from this issue.

Perhaps the issue occurs more quickly on btrfs, that I don't know, but it could happen on any filesystem. On the other hand, you should have backups. Personally, I use ZFS on two of my machines, with snapshot feature.

[vladvasiliu]

> Except if you keep overwriting a flash-based storage system, at some point that flash storage gets destroyed (wear level). You can absolutely achieve such by having a near full filesystem on flash. Mechanical harddrives or partitions don't suffer from this issue.

Wearing out is yet a different thing. I've had this happen on an SD card. It would refuse to write anything new, although it reported being mostly free. But the stuff that was already on it was readable.

I've had SD cards that got full. They didn't lose any data, and once I'd moved the things off them, they became usable again.

Granted, this was with a digital camera, so using fat32 at the time, so no fancy FS.

[nix23]

>Shit happens, so this does look like a FS bug to me, much more than PEBCAK.

Exactly, a swimming-pool should never explode if you overfill it, however it's the users responsibility to turn the water off to prevent "data/water-loss"

That's why we made filesystems, preserve and organize data and tell the user/system when it cant take anymore.

[cmurf]

Without more information on the exact mount error and btrfsck --readonly output, it's a guessing game.

In the ordinary cases, btrfs full behavior is the same as other filesystems. It gets full, you can delete files. Keep in mind deleting files on any cow filesystem is a write that consumes free space before space is freed from the delete operation. There is reserve space for this. If you hit an edge case (which would be a bug) there's currently no known data eating bugs. But it's not always obvious to the user their data hasn't been eaten if the filesystem won't mount. As in, this is indistinguishable from data loss. Nevertheless it's a serious bug so if you have a reproducer it needs to be reported.

[nix23]

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

[cmurf]

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 report in the proper venue with enough detail for someone else to reproduce.

[nix23]

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

[nix23]

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 stops writing and instead cares more about the data that's already on the platter?

BTW: It was a DC-Harddisk

[Fnoord]

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 RAID5 write hole (can be mitigated), and RAID5 issues on btrfs (which are well known). For all we know you were using RAID5 shrug. Anyway, did you file a bug report, did you contact the devs?

[nix23]

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