From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arne Jansen Subject: Re: [PATCH] btrfs: don't add both copies of DUP to reada extent tree Date: Sat, 25 Feb 2012 14:09:50 +0100 Message-ID: <4F48DD9E.7030200@gmx.net> References: <1330157387-6803-1-git-send-email-sensille@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Cc: linux-btrfs@vger.kernel.org To: Duncan <1i5t5.duncan@cox.net> Return-path: In-Reply-To: List-ID: On 02/25/12 09:33, Duncan wrote: > Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted: > >> Normally when there are 2 copies of a block, we add both to the reada >> extent tree and prefetch only the one that is easier to reach. >> This way we can better utilize multiple devices. >> In case of DUP this makes no sense as both copies reside on the same >> device. > > I'm not a coder and thus can't really read the code to know, but wouldn't > the same easier-to-reach logic apply there, only to seeking? One of the > DUPs should be easier to reach (less seeking) than the other. > Well, the commit message is kind of sloppy. The reada code collects as many blocks near to each other and reads them sequentially. From time to time it moves on to the next filled zone. That's when a longer seek happens. It doesn't try to keep these longer seeks as short as possible, instead it picks a zone on the disk where it has many blocks to read. As both parts of a DUP are filled equally, it doesn't matter which one it picks, so it is sufficient to keep track of only one half of the mirror. Things change in a multi-disk setup, as the heads can move independently. (this explanation is kind of sloppy, too) -Arne