31–40 of 55 posts
It would probably make sense to display .srht.site for submissions which match this domain pattern, similar to github.io sites.
Earlier quoted context omitted.
I loose every two years (when i test it again) a volume to btrfs, last time 2 month ago, with that simple "trick": -Fill your rootpartionion as root with "dd if=/dev/urandom of=./blabla bs=3m" -rm blabla && sync (we don't want to be unfair to such a fragile system) -Reboot and end up with unbootable / It's a mess, for a filesystem i would declare it as alpha stage.
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.
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
Earlier quoted context omitted.
> Most subvolumes can be mounted with noatime This noatime thing is an old-wive's tale that needs to die. AFAIK, most "modern" filesystems (XFS,BTRFS etc.) all default to relatime relatime maintains atime but without the overhead EDIT TO ADD: Actually,I've just done a bit of searching .... relatime has been the kernel mount default since >= 2.6.30 ! [1] [1] https://kernelnewbies.org/Linux_2_6_30 (scroll to 1.11. File…
I prefer lazyatime.
Earlier quoted context omitted.
I can vouch for how good it works. Using it on my personal laptop.
I tried ZFS-on-linux with Ubuntu 21.10 and it ate my data (ZFS panics when accessing certain files). Sure, Ubuntu does have a habit of using unstable kernels, but I was still disappointed. It should be stable at this point.
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/190...
Neat:) I would never use btrfs myself[0], but very happy to see people exploring all variations of these ideas. The one thing that's starting to bug me though, as I read blog posts about installing nixos: why is the install process so imperative/non-declarative? Once the system is up, the whole thing fits in configuration.nix, but to get there we still have to use masses of shell commands. Is anyone working on bridgi…
I loose every two years (when i test it again) a volume to btrfs, last time 2 month ago, with that simple "trick": -Fill your rootpartionion as root with "dd if=/dev/urandom of=./blabla bs=3m" -rm blabla && sync (we don't want to be unfair to such a fragile system) -Reboot and end up with unbootable / It's a mess, for a filesystem i would declare it as alpha stage.
Ideally reproduce it with mainline kernel or most recent stable. And post the details on the linux-btrfs list. They are responsive to bug reports.
If you depend on LTS kernels then it's, OK to also include in the report the problem happens with X kernel but not Y kernel. Upstream only backports a subset of fixes and features to stable. Maybe the fix was missed and should have gone to stable or maybe it was too hard to backports.
These are general rules for kernel development, it's not btrfs specific. You'll find XFS and i915 devs asking for testing with more recent kernels too.
But in any case, problems won't get fixed without a report on an appropriate list.
Earlier quoted context omitted.
> 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 pa…
>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.
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.
Earlier quoted context omitted.
I loose every two years (when i test it again) a volume to btrfs, last time 2 month ago, with that simple "trick": -Fill your rootpartionion as root with "dd if=/dev/urandom of=./blabla bs=3m" -rm blabla && sync (we don't want to be unfair to such a fragile system) -Reboot and end up with unbootable / It's a mess, for a filesystem i would declare it as alpha stage.
How does zfs handle that test?
Earlier quoted context omitted.
>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.
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…
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.
Earlier quoted context omitted.
I loose every two years (when i test it again) a volume to btrfs, last time 2 month ago, with that simple "trick": -Fill your rootpartionion as root with "dd if=/dev/urandom of=./blabla bs=3m" -rm blabla && sync (we don't want to be unfair to such a fragile system) -Reboot and end up with unbootable / It's a mess, for a filesystem i would declare it as alpha stage.
I can't reproduce this on a 5.17.5 kernel and loop device. So if you're able to trivially reproduce it, I'm guessing it's configuration specific. It's still a bug, but to find it means providing more detail about that configuration, including the kernel version. Ideally reproduce it with mainline kernel or most recent stable. And post the details on the linux-btrfs list. They are responsive to bug reports. If you dep…
Make a VM OpenSUSE or Fedora (tested just these two) fill it and see it not boot anymore...it is trivial.
Earlier quoted context omitted.
Why can't they? For example, Btrfs reserves some storage for it's internal use which should be more than enough to update the journal to fix a full filesystem.
Calculating exactly how much you need to reserve for the worst case is a near-impossible task. For example, say you try to delete a file, which is part of one of multiple identical snapshots, so deleting the file doesn't free up any space, but does require extra metadata to be written (since a new directory entry will be needed that shows the file is deleted in this snapshot only). The same operation could be done fo…
Btrfs won't issue the writes for super block update until the device says the current metadata transaction is successfully on stable media.
It is possible the filesystem is completely consistent (can be mounted, btrfsck finds no error), and yet not bootable due to the interruption of updates. Software updates are one transaction in user space but not atomic unless expressly designed for it. From the fs point of view, a software update might be broken up into dozens of fs transactions.
It's also possible the device lies about writes being on stable media. If the fs writes some metadata, does flush/FUA, then super block write, and flash/FUA, the device should only write the super block after the prior write is on stable media. If it says the first flush succeeded but that write is still happening, and the super block write goes to stable media before all the metadata writes get to stable media and there's a crash or power failure, then you can in fact have a broken filesystem. The super points to tree roots that don't exist. This is definitely a device flaw not an fs flaw.
Btrfs super blocks contain 3 backup roots. So it's possible to revert to an older and hopefully correct metadata generation (seconds to a couple minutes ago). But this has limited recovery potential. It's also completely thwarted right now if you use any discard mount option on an SSD because discard will ask the device to garbage collect recently freed metadata blocks. So the backup root trees pointed to by the super may already be zeros when they're needed.
But any need for backup roots already means some kind of device (firmware) flaw.