On Tue, May 17, 2016 at 3:58 PM, Goni Zahavy <goni1993@xxxxxxxxx> wrote: > On 5/18/16, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> On Tue, May 17, 2016 at 2:27 PM, Goni Zahavy <goni1993@xxxxxxxxx> wrote: >>> Guys, just remember that this crappy-installer behavior works >>> "as-expected" >>> on every other filesystem. >> >> It also fails as expected on every other file system if the upgrade is >> interrupted for reasons that have nothing to do with the file system; >> what's in common is the lack of a fail safe upgrade design. And this >> is not a ding on Ubuntu, it's a widespread and well recognized risk. >> All that's happening here is Btrfs has one more vector to expose that >> deficiency. > > I fully agree, but I talked about the "many small files unpacked to > temp on disk location then copied.." which is just plain badness I think the idea is that if it's overwriting in the live tree as it unpacks, there's a long time where it can be interrupted and any interruption puts the system in an ambiguous state with a mix of old and new binaries. Where if the unpacking happens elsewhere and is then moved, it's not committed until fsync of files and containing directory. While it can still be interrupted the time frame for this is much smaller so there's a better chance you get all old files or all updated files, and not some in between state. It might be a case of necessity rather than preferred design. > It's great that we have workarounds for the user/distribution to > apply. And If this is a known issue, I would expect that Peter Kese > would be answered here with "it's a known issue, here is how you can > work around it the next time. And it was written in underlined bold > warning on this wiki page. Stay tuned.". Known issue yes. https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21 But it can be triggered by different workloads and it may not always be that the fs can't allocate a new metadata chunk. It's a tricky problem. And it doesn't always happen. > In addition, I would expect bugs like this one that hit even simple > single-mode setups to be prioritized way way higher then any new > feature or even some existing advanced feature enhancements. Well I know at least one of the three upstream maintainers has been working on the enospc problem since at least 2009, until at least March of this year when his "Enospc rework" patches for review popped up on the list. That work is in linux-next right now, so it looks like it appears in kernel 4.7. But that's maybe orthogonal to the trickiness of getting df to report something both semi-sane and consistently so, for the inevitable and enduring apps that'll remain naive, as Austin aptly puts it, about the actual space available on the file system. The problem there is that there are in effect two free spaces on Btrfs depending on what and how much is going to get written. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
