On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo <quwenruo@xxxxxxxxxxxxxx> wrote: > Oh, converted... > That's too bad. :( > > [[What's wrong with convert]] > Although btrfs is flex enough in theory to fit itself into the free space of > ext* and works fine, > But in practice, ext* is too fragmental in the standard of btrfs, not to > mention it also enables mixed-blockgroup. > Oh oh :/ > > [[Recommendations]] > I'd recommend to delete the ext*_img subvolume and rebalance all chunks in > the fs if you're stick to the converted filesystem. > Already done (well the rebalance crashed towards the end both time with the read only error, but someone on #btrfs looked at my partition stats and said it was probably good enough) > Although the best practice is staying away from such converted fs, either > using pure, newly created btrfs, or convert back to ext* before any balance. > Unfortunately I don't have enough hard drive space to do a clean btrfs, so my only way to use btrfs for that partition was a conversion. > [[But before that, just try something]] > But you have already provided some interesting facts. As the filesystem is > high fragmented, I'd like to recommend to do some little test: > (BTW I assume you don't use some special mount options) Current mount options in fstab: btrfs defaults,noatime,compress=lzo,space_cache,autodefrag 0 0 It's the same as my other btrfs partitions, apart from the fact that they are on a SSD and way smaller. > To test if it's the space cache causing the mount speed drop. > > 1) clear page cache > # echo 3 > /proc/sys/vm/drop_caches > 2) Do a normal mount > Just as what you do as usual, with your normal mount options > Record the mount time 0.01s user 0.42s system 0% cpu 1:01.70 total > 3) umount it. not asked but might as well: 0.00s user 0.65s system 1% cpu 35.536 total > 4) clear page cache > # echo 3 > /proc/sys/vm/drop_caches > 5) mount it with "clear_cache" mount option > It may takes sometime to clear the existing cache. > It's just used to clear space cache. > Don't compare mount time! Yes I know it's supposed to be slower :) although... it was pretty much the same actually: 0.01s user 0.44s system 0% cpu 1:02.07 total > 6) umount it > 7) clear page cache > # echo 3 > /proc/sys/vm/drop_caches Is it ok if that value never changed since 1) ? > 8) mount with "nospace_cache" mount option > To see if there is obvious mount time change. > 0.00s user 0.44s system 0% cpu 1:01.86 total > Hopes that's the space cache thing causing the slow mount. > But don't expect it too much anyway, it's just one personal guess. > Unfortunately it is about the same :/ > After the test, I'd recommend to follow the [[Recommendations]] if you just > want a stable filesystem. > I am already within these recommendations I think. Thanks! -- 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
