On Thu, 2014-10-23 at 15:23 +0200, Petr Janecek wrote: > Hello Gui, > > > Oh, it seems that there are btrfs with missing devs that are bringing > > troubles to the @open_ctree_... function. > > what do you mean by "missing devs"? I have no degraded fs.
Ah, sorry, I'm too focused on the problem that Anand's script pointed out. Ignore this "missing devs". > The time "btrfs fi sh" spends scanning disks of a filesystem seems to > be proportional to the amount of data stored on them: on a completely > idle system, of ~20s total time it spends 10s scanning each of /mnt/b > and /mnt/b0, and almost no time on /mnt/b3 (which is the biggest) > > Filesystem Size Used Avail Use% Mounted on > /dev/sdm 5.5T 2.4T 2.1T 54% /mnt/b > /dev/sda 5.5T 2.5T 3.1T 45% /mnt/b0 > /dev/sde 7.3T 90G 5.4T 2% /mnt/b3 For your original problems: o error messages: The concurrency problem exists as Anand said. As you said, running balance & cp lead to such messages, so I think there are some unintentional redundency works over the mounted devices when dealing with umounted ones. I'll try to o stalling: This may be due to concurrency problem either. After the first problem handled, let's see what happens. Thanks, Gui > > Thanks, > > Petr > -- > 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 -- 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
