Hi list, I have a few large image files (VMware workstation VMDKs and TrueCrypt containers) which I routinely back up over the network to a btrfs raid10 volume via bigsync (https://code.google.com/p/bigsync/). The VM images in particular get really fragmented due to CoW, which is expected. I haven''t yet switched off CoW on the backups directory mainly to experiment and see what would happen. So doing that would be an acceptable solution to my issue below, but I''m curious as to what''s happening. Filefrag reports that a VM image file has 4744 extents. If I run btrfs fi defrag -v /path/to/file.vmdk, it returns immediately with no messages but an exit status of 20, and running filefrag again shows that no defragmentation has taken place. This is on Ubuntu 13.04, kernel 3.9.0-rc8 and v0.20-rc1 of the tools, and the file in the example is 34GB. Any ideas what''s happening here? Cheers, ---tim -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 11. Mai 2013, 12:27:09 schrieb Tim Eggleston:> Hi list, > > I have a few large image files (VMware workstation VMDKs and TrueCrypt > containers) which I routinely back up over the network to a btrfs raid10 > volume via bigsync (https://code.google.com/p/bigsync/). > > The VM images in particular get really fragmented due to CoW, which is > expected. I haven''t yet switched off CoW on the backups directory mainly > to experiment and see what would happen. So doing that would be an > acceptable solution to my issue below, but I''m curious as to what''s > happening. > > Filefrag reports that a VM image file has 4744 extents. If I run btrfs > fi defrag -v /path/to/file.vmdk, it returns immediately with no messages > but an exit status of 20, and running filefrag again shows that no > defragmentation has taken place. > > This is on Ubuntu 13.04, kernel 3.9.0-rc8 and v0.20-rc1 of the tools, > and the file in the example is 34GB. > > Any ideas what''s happening here?Yes. The command just triggers the defragmentation which takes place in the background. Try a "sync" afterwards :) Ciao, -- Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Yes. The command just triggers the defragmentation which takes place > in the > background. Try a "sync" afterwards :)Sorry Martin, I should have specified that I wondered if it was like the scrub operation in that respect, so I left it several hours before running filefrag again (and seeing that the number of extents was unchanged). Top and iostat also don''t report any particular activity immediately after running the defrag command, so it doesn''t look like much if anything is happening. By the way, this is on a filesystem mounted with -o autodefrag, although per the docs I wasn''t expecting the auto defragmentation to work with the big VM images. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 11. Mai 2013, 17:57:11 schrieb Tim Eggleston:> > Yes. The command just triggers the defragmentation which takes place > > in the > > background. Try a "sync" afterwards :) > > Sorry Martin, I should have specified that I wondered if it was like > the scrub operation in that respect, so I left it several hours before > running filefrag again (and seeing that the number of extents was > unchanged). Top and iostat also don''t report any particular activity > immediately after running the defrag command, so it doesn''t look like > much if anything is happening.Hmmm, thats strange. Last time I tried it here, it worked.> By the way, this is on a filesystem mounted with -o autodefrag, > although per the docs I wasn''t expecting the auto defragmentation to > work with the big VM images.This worked here to some extent with Virtualbox images which quickly got up to several ten thousands extents. -- Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, May 11, 2013 at 05:57:11PM +0100, Tim Eggleston wrote:> > >Yes. The command just triggers the defragmentation which takes > >place in the > >background. Try a "sync" afterwards :) > > Sorry Martin, I should have specified that I wondered if it was like > the scrub operation in that respect, so I left it several hours > before running filefrag again (and seeing that the number of extents > was unchanged). Top and iostat also don''t report any particular > activity immediately after running the defrag command, so it doesn''t > look like much if anything is happening. > > By the way, this is on a filesystem mounted with -o autodefrag, > although per the docs I wasn''t expecting the auto defragmentation to > work with the big VM images.Hi Tim, Btrfs defrag tries to merge small extents in overall, so maybe the extents in your big VM images are large enough although there are 4000+ extents. And autodefrag is also only for small extents(like a write less then 16k). So, you may check if those extents are already big enough :) thanks, liubo> -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html