Martin Steigerwald posted on Wed, 15 Jan 2014 20:40:29 +0100 as excerpted: > Am Mittwoch, 15. Januar 2014, 19:05:41 schrieb Duncan: >> But just as my already allocated mixed-mode chunks were just about full >> and I needed another one allocated to complete the job, so your data >> chunks are full or very close, according to btrfs fi df, and you need a >> new one allocated (and if the file is greater than a gig in size, >> likely more than one) to finish the job. >> >> And in both our cases, there's plenty of unallocated space in the pool, >> but for whatever reason, btrfs isn't allocating that new chunk when it >> should! Why, I can't say, but as I mentioned, I was able to work >> around the problem here by trying the remaining files in a different >> order, and at some point, btrfs figured out it needed that new chunk >> allocated, and everything went fine after that. > I think you can cause BTRFS to allocate a chunk or more by creating a > file with the fallocate command. Unless BTRFS doesn´t do it due to a bug > and errors out with no space left. > > fallocate gives also an easy way to find out how much it might still > allocate and at what point it fails – and that without writing tons of > data first. fallocate just triggers allocation and does not write any > actual data. Good idea. =:^) I don't have the problem ATM so I can't test it, but hopefully Tomasz can. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
