On Mar 4, 2014, at 11:54 AM, Michael Russo <m...@papersolve.com> wrote:
> Chris Murphy <lists <at> colorremedies.com> writes: >> Based on my reading of the man page, I think it's expected. >> You either need -s -l or -t. > > Ok, although the man page uses [ ] instead of < > and something > does happen if I don't add them. But if I use "-t 1" wouldn't that > get everything? Yeah you're right, you do get a default behavior but I think it's really permissive. I've thrown 30000 extent files at it, and it's still 30000 extents afterward. > >> >>> Now I've gotten >>> it down to only 2 5GB segments that won't move. >> >> Another way would be to just copy it (not reflink) and delete the original. >> > > How can I find out what file is on the block group that > it's having a problem with? I think that's btrfs-debug-tree -b ? But don't hold me to that. I haven't done enough debugging to find files from block numbers. Another that might be relevant is btrfs inspect-internal logical-resolve. Chris Murphy -- 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
