From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aHQf3-0006MZ-FJ for mharc-grub-devel@gnu.org; Fri, 08 Jan 2016 01:36:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHQf0-0006M7-U1 for grub-devel@gnu.org; Fri, 08 Jan 2016 01:36:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHQex-0002VN-OS for grub-devel@gnu.org; Fri, 08 Jan 2016 01:36:30 -0500 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:34939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHQex-0002VA-HG for grub-devel@gnu.org; Fri, 08 Jan 2016 01:36:27 -0500 Received: by mail-lb0-x233.google.com with SMTP id bc4so218968545lbc.2 for ; Thu, 07 Jan 2016 22:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=JnjXLrUbWb/bhJB4QHAvvzYK+osemx/imPoCzgUIg+c=; b=Hqqx18pVEia/mOwnclG+iXR97TC2qpj2yN9+dVEW350yzlyGOPNO4lk454lnaoMY2z IrMMfCzmXiZFb+0AksoBjxn1GoiVTbGYFT7MRdWyRu0EekTytXdSITT7w/7Tm53sQgw8 gOwkVkzXT60P/1tkFLEWUQDgklkp3o3fY9aCgcHke2WzGeeQMgpXE+/ATNSS+c8/b8kP sfsHMdM7H11Q9lePG9IpP4jBx/C9GrM3To1poEaVI7sGa0Uc6/1/nR0LAa3vasxQZyuB Tg4F9D1n8/D4xdEH9JGhG38AHDvD8e2aYc5Y/6mQdPPp0KRG+8UeA9k0w8yvV4nTF1oG +/4g== X-Received: by 10.112.141.70 with SMTP id rm6mr31960569lbb.94.1452234986695; Thu, 07 Jan 2016 22:36:26 -0800 (PST) Received: from [192.168.1.41] (ppp91-76-25-247.pppoe.mtu-net.ru. [91.76.25.247]) by smtp.gmail.com with ESMTPSA id m21sm11937611lfe.29.2016.01.07.22.36.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jan 2016 22:36:25 -0800 (PST) Subject: Re: btrfs trim erases bootloader area To: Christoph Anton Mitterer , fdmanana@gmail.com, Chris Murphy References: <568EB86F.7070800@gmail.com> <1452217455.6686.10.camel@scientia.net> From: Andrei Borzenkov Message-ID: <568F58E8.8020707@gmail.com> Date: Fri, 8 Jan 2016 09:36:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1452217455.6686.10.camel@scientia.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::233 Cc: The development of GNU GRUB , "linux-btrfs@vger.kernel.org" X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 06:36:32 -0000 08.01.2016 04:44, Christoph Anton Mitterer пишет: > Hey. > > Just a followup on this: > GPT and some others (e.g MD RAID) store data in the end of the device. > > It's clear that when the fs is made inside a partition, this shouldn't > be seen (and thus TRIMmed) anyway... but can btrfs be installed e.g. > directly on the device while that continues to hold the GPT (by btrfs > simply always starting at some byte offset)? If btrfs size includes metadata at the end of device - arguably it is user error; it should not happen. If user explicitly excluded metadata (mkfs.btrfs -b ) but btrfs still attempts to trim beyond end of filesystem - this is obviously bug and should not happen. I do not understand much of btrfs internals to know if this is possible. Note that corner case is when filesystem size is not multiple of trim units size. Then incomplete chunks(s) at the beginning and end should always be skipped. > If so, then one may possibly need to extend that patch for the end of > the device. > > Cheers, > Chris. >