Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7219407ybc; Thu, 28 Nov 2019 13:18:03 -0800 (PST) X-Google-Smtp-Source: APXvYqyCFim6FUy3hlFJ6losnP5aPlKHiZ/cj2WNrVbgO0vqmm6TNqiOsG0gsfjG6BMYXLxEHEmX X-Received: by 2002:a17:906:d8b7:: with SMTP id qc23mr10385880ejb.117.1574975883446; Thu, 28 Nov 2019 13:18:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574975883; cv=none; d=google.com; s=arc-20160816; b=mpUTKjWDcN3drKQyeUwImds5JyJlVsGwRa04935SHJITTpWY2QN1AKGa6BQ/Q0Blwu rC6rMmnGcUPkv4389RyRJZqJHjntr3gJulPmqXm1bcCKICMdeupqZWIBUf2qG/tPwEmS nZhsMJBOzqt/b1jnjBYVuN+iVi+GNrOFfm3cIuuHVcbFG9u6TB37eEosdZhtWCGnLezR lmhUjlys4hma0xOt9Gv6vRg+xEgTYUTCA9staNZo9JG0CV2u+3F1HFTi1qwobdaEZ8hK R/P8GLaS7fcG6uyREXsaFEKwgE4STfvSESJKA4eMdcY1Iy9Iz1bWfWJENx6GOPfdvz6/ OrNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=V2hTQpM7Wmt+gznJCfJu+dwi/Aj7hjkqNmYjyopWiaw=; b=GQjoQBx7xngwLvX3Y0biqj8/eJr1iY1Li0j/Z5jsGzEXfxP5dUkEBKQ0B98NavEoxn BUJgct4/DLHzZaM1pMDZgUezPCIcdfuQYwFQD7fvT1hSnp6APAIZsXiPARPzGky4jgqk WcPH5TuRzOavfOgKbOHaBZyLSml47uoIOc/5ldwriRFr0TqTqRbJIIsSHVYKujf46fut EFiU189kGdjHoi/NnNnK6IDmQBzCXsS2qsYoZh0zlD0onkGj4XVVjBGXbKEENX24HVFn 7lbgs37TS/tB35bk0dTMikzGXUNp5BBc0uUAoNicYJJwCx3opU/qrzORbKpj575Qv+m6 V/Tg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bx7si6963345edb.403.2019.11.28.13.17.28; Thu, 28 Nov 2019 13:18:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726616AbfK1VR1 (ORCPT + 99 others); Thu, 28 Nov 2019 16:17:27 -0500 Received: from mail.phunq.net ([66.183.183.73]:35968 "EHLO phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726558AbfK1VR1 (ORCPT ); Thu, 28 Nov 2019 16:17:27 -0500 Received: from [172.16.1.14] by phunq.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.92.3) (envelope-from ) id 1iaRAD-0006J6-Aq; Thu, 28 Nov 2019 13:17:25 -0800 Subject: Re: [RFC] Thing 1: Shardmap fox Ext4 To: "Theodore Y. Ts'o" Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, OGAWA Hirofumi References: <176a1773-f5ea-e686-ec7b-5f0a46c6f731@phunq.net> <20191127142508.GB5143@mit.edu> <20191128022817.GE22921@mit.edu> From: Daniel Phillips Message-ID: <4c8c3948-5aa1-6a41-c0a9-cc694e89a579@phunq.net> Date: Thu, 28 Nov 2019 13:17:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191128022817.GE22921@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2019-11-27 6:28 p.m., Theodore Y. Ts'o wrote: > The use of C++ with templates is presumably one of the "less so" > parts, and it was that which I had in mind when I said, > "reimplementing from scratch". Ah, duopack and tripack. Please consider the C code that was replaced. by those. See tons of bogus extra parameters resulting in nonsense like this: set_entry(shard_entry(shard, bucket), key & bitmask(shard->lowbits), loc, next, shard->locbits, nextbits); which in the c++ version looks like: *entry = {trio.pack(next, loc, key & bitmask(lowbits))}; They generate roughly identical machine code, but I know which one I prefer to maintain. That said, porting back to C (in progress right now) includes substituting some appropriate macro code for those sweet little variable field width structure templates. Which by the way are central to Shardmap's scalability and performance. These are what allow the index entry to stay at just 8 bytes over the entire range from one entry to one billion. So right, tripack and duopack weill be reimplemented from scratch, using the template code as a model. Basically just expanding the templates by hand and adding in some macro sugar for clarity. Shardmap itself does not need to be rewritten from scratch in order to port to kernel, far from it. Regards, Daniel