From patchwork Tue Aug 19 22:10:55 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zach Brown X-Patchwork-Id: 4746131 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 89707C0338 for ; Tue, 19 Aug 2014 22:11:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A9E88200FE for ; Tue, 19 Aug 2014 22:11:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 960A4200EC for ; Tue, 19 Aug 2014 22:11:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751398AbaHSWK4 (ORCPT ); Tue, 19 Aug 2014 18:10:56 -0400 Received: from tetsuo.zabbo.net ([50.193.208.193]:58136 "EHLO tetsuo.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751208AbaHSWK4 (ORCPT ); Tue, 19 Aug 2014 18:10:56 -0400 Received: from localhost (lenny.home.zabbo.net [192.168.242.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tetsuo.zabbo.net (Postfix) with ESMTPSA id 637F872004CF; Tue, 19 Aug 2014 15:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zabbo.net; s=default; t=1408486255; bh=w1Bifw18r4AGr3iNgr+dwI8apTI7oSG4TQstpRzr6k8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hH4EdbuvHT9sWHTD4S7D+PW7qog+HpCGCFu+dLPv5LDA4ZS+r4vs+s+SSyGYUcAdD ZoWEd3GuHvncaK2FBDRZYgpTTn7ZFdyqkiEZhSoxn4FU+IYtoSvQ14ZMucwFjoglr0 axYk1CnSKnw7W+6zhaPzn1502jBeX1nU23REcyPg= Date: Tue, 19 Aug 2014 15:10:55 -0700 From: Zach Brown To: Klaus Holler Cc: linux-btrfs@vger.kernel.org Subject: Re: btrfs receive problem on ARM kirkwood NAS with kernel 3.16.0 and btrfs-progs 3.14.2 Message-ID: <20140819221055.GI429@lenny.home.zabbo.net> References: <53F0A3B2.80709@gmx.at> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <53F0A3B2.80709@gmx.at> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, LOTS_OF_MONEY,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID, UNPARSEABLE_RELAY,URIBL_WS_SURBL autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun, Aug 17, 2014 at 02:44:34PM +0200, Klaus Holler wrote: > Hello list, > > I want to use an ARM kirkwood based NSA325v2 NAS (dubbed "Receiver") for > receiving btrfs snapshots done on several hosts, e.g. a Core Duo laptop > running kubuntu 14.04 LTS (dubbed "Source"), storing them on a 3TB WD > red disk (having GPT label, partitions created with parted). > > But all the btrfs receive commands on 'Receiver' fail soon with e.g.: > ERROR: writing to initrd.img-3.13.0-24-generic.original failed. File > too large > ... and that stops reception/snapshot creation. ... > Increasing the verbosity with "-v -v" for btrfs receive shows the > following differences between receive operations on 'Receiver' and > 'OtherHost', both of them using the identical inputfile > /boot/.snapshot/20140816-1310-boot_kernel3.16.0.btrfs-send > > * the chown and chmod operations are different -> resulting in > weird/wrong permissions and sizes on 'Receiver' side. > * what's "stransid", this is the first line that differs This is interesting, thanks for going to the trouble to show those diffs. That the commands and strings match up show us that the basic tlv header chaining is working. But the u64 attribute values are sometimes messed up. And messed up in a specific way. A variable number of low order bytes are magically appearing. (gdb) print/x 11709972488 $2 = 0x2b9f80008 (gdb) print/x 178680 $3 = 0x2b9f8 (gdb) print/x 588032 $6 = 0x8f900 (gdb) print/x 2297 $7 = 0x8f9 Some light googling makes me think that the Marvell Kirkwood is not friendly at all to unaligned accesses. The (biting tongue) send and receive code is playing some games with casting aligned and unaligned pointers. Maybe that's upsetting the arm toolchain/kirkwood. Does this completely untested patch to btrfs-progs, to be run on the receiver, do anything? - z --- 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 diff --git a/send-stream.c b/send-stream.c index 88e18e2..4f8dd83 100644 --- a/send-stream.c +++ b/send-stream.c @@ -204,7 +204,7 @@ out: int __len; \ TLV_GET(s, attr, (void**)&__tmp, &__len); \ TLV_CHECK_LEN(sizeof(*__tmp), __len); \ - *v = le##bits##_to_cpu(*__tmp); \ + *v = get_unaligned_le##bits(__tmp); \ } while (0) #define TLV_GET_U8(s, attr, v) TLV_GET_INT(s, attr, 8, v)