After unmounting: [251818.992992] BTRFS error (device sdc1): cleaner transaction attach returned -30 and remounting: [251837.393750] BTRFS info (device sdc1): disk space caching is enabled the disk again resizes Data. On Mon, Jan 11, 2016 at 5:02 PM, cheater00 . <cheater00@xxxxxxxxx> wrote: > I triggered the bug again, attaching log. There were some usb resets, > but they happened 23 minutes before the fs crashed. > > At mount, the output of btrfs fi df -g was like this: > Data, single: total=2080.01GiB, used=2078.80GiB > System, DUP: total=0.01GiB, used=0.00GiB > System, single: total=0.00GiB, used=0.00GiB > Metadata, DUP: total=5.50GiB, used=3.73GiB > Metadata, single: total=0.01GiB, used=0.00GiB > GlobalReserve, single: total=0.50GiB, used=0.00GiB > > Now it is: > Data, single: total=2094.01GiB, used=2092.26GiB > System, DUP: total=0.01GiB, used=0.00GiB > System, single: total=0.00GiB, used=0.00GiB > Metadata, DUP: total=5.50GiB, used=3.79GiB > Metadata, single: total=0.01GiB, used=0.00GiB > GlobalReserve, single: total=0.50GiB, used=0.00GiB > > The file being copied at the time was 954 MB. > > > > On Mon, Jan 11, 2016 at 3:10 PM, Austin S. Hemmelgarn > <ahferroin7@xxxxxxxxx> wrote: >> On 2016-01-11 08:11, cheater00 . wrote: >>> >>> On Mon, Jan 11, 2016 at 2:05 PM, Austin S. Hemmelgarn >>> <ahferroin7@xxxxxxxxx> wrote: >>>> >>>> On 2016-01-09 16:07, cheater00 . wrote: >>>>> >>>>> >>>>> Would like to point out that this can cause data loss. If I'm writing >>>>> to disk and the disk becomes unexpectedly read only - that data will >>>>> be lost, because who in their right mind makes their code expect this >>>>> and builds a contingency (e.g. caching, backpressure, etc)... >>>> >>>> >>>> If a data critical application (mail server, database server, anything >>>> similar) can't gracefully handle ENOSPC, then that application is broken, >>>> not the FS. As an example, set up a small VM with an SMTP server, then >>>> force the FS the server uses for queuing mail read-only, and see if you >>>> can >>>> submit mail, then go read the RFCs for SMTP and see what clients are >>>> supposed to do when they can't submit mail. A properly designed piece of >>>> software is supposed to be resilient against common failure modes of the >>>> resources it depends on (which includes ENOSPC and read-only filesystems >>>> for >>>> anything that works with data on disk). >>>>> >>>>> >>>>> >>>>> There's no loss of data on the disk because the data doesn't make it >>>>> to disk in the first place. But it's exactly the same as if the data >>>>> had been written to disk, and then lost. >>>>> >>>> No, it isn't. If you absolutely need the data on disk, you should be >>>> calling fsync or fdatasync, and then assuming if those return an error >>>> that >>>> none of the data written since the last call has gotten to the disk (some >>>> of >>>> it might have, but you need to assume it hasn't). Every piece of >>>> software >>>> in wide usage that requires data to be on the disk does this, because >>>> otherwise it can't guarantee that the data is on disk. >>> >>> >>> I agree that a lot of stuff goes right in a perfect world. But most of >>> the time what you're running isn't a mail server used by billions of >>> users, but instead a bash script someone wrote once that's supposed to >>> do something, and no one knows how it works. >>> >> And that's why no sane person does stuff like that on enterprise level >> systems. And even then, if the person writing the bash script actually >> knows what they're doing, they will be using the 'sync' command to ensure >> data integrity when they actually need it, or they will write their script >> in such a way that it gracefully handles a partial run. -- 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
