On 10/24/2014 10:28 PM, Duncan wrote: > Robert White posted on Fri, 24 Oct 2014 19:41:32 -0700 as excerpted: > >> On 10/24/2014 04:49 AM, Marc MERLIN wrote: >>> On Thu, Oct 23, 2014 at 06:04:43PM -0500, Larkin Lowrey wrote: >>>> I have a 240GB VirtualBox vdi image that is showing heavy >>>> fragmentation (filefrag). The file was created in a dir that was >>>> chattr +C'd, the file was created via fallocate and the contents of >>>> the orignal image were copied into the file via dd. I verified that >>>> the image was +C. >>> To be honest, I have the same problem, and it's vexing: >> If I understand correctly, when you take a snapshot the file goes into >> what I call "1COW" mode. > Yes, but the OP said he hadn't snapshotted since creating the file, and > MM's a regular that actually wrote much of the wiki documentation on > raid56 modes, so he better know about the snapshotting problem too. > > So that can't be it. There's apparently a bug in some recent code, and > it's not honoring the NOCOW even in normal operation, when it should be. > > (FWIW I'm not running any VMs or large DBs here, so don't have nocow set > on anything and can and do use autodefrag on all my btrfs. So I can't > say one way or the other, personally.) >
Correct, there were no snapshots during VM usage when the fragmentation occurred. One unusual property of my setup is I have my fs on top of bcache. More specifically, the stack is md raid6 -> bcache -> lvm -> btrfs. When the fs mounts it has mount option 'ssd' due to the fact that bcache sets /sys/block/bcache0/queue/rotational to 0. Is there any reason why either the 'ssd' mount option or being backed by bcache could be responsible? --Larkin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
