All of lore.kernel.org
 help / color / mirror / Atom feed
* Two Issues with Btrfs Delayed Cleaner Process (linux-next)
@ 2012-10-08 17:41 Mitch Harder
  2012-10-12 10:06 ` Alex Lyakas
  0 siblings, 1 reply; 2+ messages in thread
From: Mitch Harder @ 2012-10-08 17:41 UTC (permalink / raw)
  To: linux-btrfs

I've run across two issues with the delayed cleaner process running a
kernel based on the 3.6.0 btrfs-next branch in Josef's git repository.

(1)  I'm getting an error when trying to list my subvolumes whenever
the cleaner thread is running:

# btrfs su li /mnt/benchmark/
ERROR: Failed to lookup path for root 0 - No such file or directory

As long as the cleaner thread is idle, I can run this command without error.

(2)  I ran into an issue on a slower x86 machine (AMD Athlon XP 2600+)
where the cleaner thread literally required an hour to finish deleting
a subvolume that contained the sources for a kernel I had previously
built.

The machine was responsive the whole time, and the cleaner thread
never required much more than 5-10% of the CPU, leaving ample idle
time.

Interestingly, every attempt to replicate this behaviour resulted in
the cleaner thread finishing in a few seconds.

My first issue replicates every time the cleaner thread is running.

I'll need to work on the second issue for a while to see if I can get
it to replicate.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Two Issues with Btrfs Delayed Cleaner Process (linux-next)
  2012-10-08 17:41 Two Issues with Btrfs Delayed Cleaner Process (linux-next) Mitch Harder
@ 2012-10-12 10:06 ` Alex Lyakas
  0 siblings, 0 replies; 2+ messages in thread
From: Alex Lyakas @ 2012-10-12 10:06 UTC (permalink / raw)
  To: Mitch Harder; +Cc: linux-btrfs, miaox

Hi Mitch,
for issue (1) I proposed a small patch here:
http://www.spinics.net/lists/linux-btrfs/msg19574.html
which resolves it for me. The problem is that there are subvolumes
that still exist in the root tree, but don't have their ROOT_BACKREF
entry anymore.

However, Miao's rework of the subvolume listing code was to improve
its scalability, which my quick patch somewhat breaks....So you can
try the patch meanwhile, but Miao will probably want to something
smarter...

Thanks,
Alex.



On Mon, Oct 8, 2012 at 7:41 PM, Mitch Harder
<mitch.harder@sabayonlinux.org> wrote:
> I've run across two issues with the delayed cleaner process running a
> kernel based on the 3.6.0 btrfs-next branch in Josef's git repository.
>
> (1)  I'm getting an error when trying to list my subvolumes whenever
> the cleaner thread is running:
>
> # btrfs su li /mnt/benchmark/
> ERROR: Failed to lookup path for root 0 - No such file or directory
>
> As long as the cleaner thread is idle, I can run this command without error.
>
> (2)  I ran into an issue on a slower x86 machine (AMD Athlon XP 2600+)
> where the cleaner thread literally required an hour to finish deleting
> a subvolume that contained the sources for a kernel I had previously
> built.
>
> The machine was responsive the whole time, and the cleaner thread
> never required much more than 5-10% of the CPU, leaving ample idle
> time.
>
> Interestingly, every attempt to replicate this behaviour resulted in
> the cleaner thread finishing in a few seconds.
>
> My first issue replicates every time the cleaner thread is running.
>
> I'll need to work on the second issue for a while to see if I can get
> it to replicate.
> --
> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-10-12 10:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-08 17:41 Two Issues with Btrfs Delayed Cleaner Process (linux-next) Mitch Harder
2012-10-12 10:06 ` Alex Lyakas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.