From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E156633FE36 for ; Wed, 4 Mar 2026 17:03:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772643790; cv=none; b=t8TmMZWoxQvKtAXv+ytV7sjyMo/vDwXpXBcBGb1oqqcIufqicmJPJyWoXgLfiHcJloKgQP9utayYaT/MtHQzFbh5qBAB8TjzZ38YF4Mi++78M4Ia09D4xzaOGyhs7xBpy44VLItBssPXAkwNAzMuDXPZhmaG4BSpNIc2p4rp4qY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772643790; c=relaxed/simple; bh=pou19ySUG13nKwdNilYFWsWzD48h80SFbDhoSXZs2Eo=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=ItsZ24xWqVRLSUD3GKu4/IiRm8pdcJDzWXm1NngQehbXdbm5FPIxu70MccfK8MV3FHjzTF8b83QSntL6PJ77xi8CShA8dWH2vXzXQDe8TTJq5igRPRGbx5WnaIOx031AgdCz2az/00HS5+2pB0aNfXAWmXKZuB+x8wbWUVier/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IX7pdby9; arc=none smtp.client-ip=209.85.160.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IX7pdby9" Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-415c8a4d2e6so849883fac.0 for ; Wed, 04 Mar 2026 09:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772643788; x=1773248588; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:from:to:cc:subject:date :message-id:reply-to; bh=FIGftf4Q7+flNLtv3jfYKmAHLlNWID9r3UuJe4t8yTc=; b=IX7pdby9IC846Oxu9sdJfTafgp8A6LYNiyQWl/SDx5DSND8WeHsULgB33xKXVcbaqP jDZ+3gFznrjaDg+jArkdg/eeyQa5OEWWGhMmeWSbzuFI2eq5JUW3bCdwqfydkN3OtFyf 5995AGSUbdhKWZnidlg+H2N/R2D8e9oKAzZvDi6MS4sa0xCwFlPTvJe6qlNiQdTa1iZS HYSyJ2K/2P2oDCU6+DkPsvyNkB5eYXnnFUl6Y6SU8w/T0ejLycqqXbdJJO9qTgEOw2Nj d+UDLdkTQYnFguvZarIACD2ic9+9v5bJ9uSfR8iUMS5MCzLmINrEUTjA3UxaloZfL1mk MyEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772643788; x=1773248588; h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FIGftf4Q7+flNLtv3jfYKmAHLlNWID9r3UuJe4t8yTc=; b=mk0jB1jeKtxBwU71My7M9xIAY0EhzQbE1oySQyTN0qZgDck0SaiRXRbJMGP9+MYKP5 qhu3tCwb+B5Dlqlrf2Z9MfeoF+ZtFty8F1Qch5IiUdgpwzwiI+ZYbzdVKbkMN9d82P/Y Q1p7v4rOwfE+SZNRCvY79Pd51aviBX/YtBx3U8vR1p3fU+wX/DNcX1mKm37On90iRK2v 2zM9TMwwbqZjSBVGAWgBUwh/e26ZW2UOF8+Au6IxEx9WQMuqC4XrlqMTPltQIj23rDN1 i0WQH/TvFrM3igkbOBgQopNDfhArio2KhX/woPFpEVgIh7XiQ6FbdzNckVIp4vOFyRch dEqg== X-Forwarded-Encrypted: i=1; AJvYcCVeWy3ahixSkHpkoZ+Hz+D6qSdmNzbDZmepwYIDv0UIzCf8twNFesIGYTsZbaE5N/ojGhqoa/Q/ggsBF24=@vger.kernel.org X-Gm-Message-State: AOJu0YxezEcu/8GW6qmln4omV2ujwgeskNJwnu8t0nCHKSfci6dXneCK CDARQBEIrLeVEM+GN85luwPp88DZIeR/GMGrh5I81U12H4sCsuO8uQk= X-Gm-Gg: ATEYQzw/iRUUqne6BTHZY7sl5O0UgkvwEFe+K9JlWTZnVKp/YWQHIs09PruXd6Vy4DA F/OW8KaKaPS5V7zzhud0X5arF2THdVBpvHdwJV7q6JFrKXGyGVDXKg7SiESzlfTAWBMtr5vOjq5 N8gwZV92HWwOv8YGWfu07j2ul3kE7YjfjXjxNnkiKaNkr7Y+UbZBuu5I+vYqOtWAQrgO9n2N2w3 KOBt8r1K8BFw1QbDkyrno0e+BCuFL1WguCU6Bl65nFiGS4qshbLgfcH24F2wJjb6IcQLslC0Ct9 6MuHVAchSHJO1X6SkBVwMhIWEjZu8UfacSYTAhQkJpyDJjS+Hsiq08r+erIzHejATSMHU5vB8g3 /Mojt3SioLmkYVs4Xw58uUOK1IipNYpCGmQ4rTmE8sou4k05fFuLMmkSS3r+xhV6LKO6tKsxyRB hz7J1eNWaLiaIQGlN2ABn9HbQrIYeqDn4Km89ilQ0ETMvoYlB73Rw= X-Received: by 2002:a05:6870:b30f:b0:3ec:554d:c222 with SMTP id 586e51a60fabf-416abb50667mr1515975fac.46.1772643787362; Wed, 04 Mar 2026 09:03:07 -0800 (PST) Received: from [120.7.1.23] (135-23-93-252.cpe.pppoe.ca. [135.23.93.252]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cbbf736cfasm1648998285a.49.2026.03.04.09.03.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 09:03:06 -0800 (PST) Subject: Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64 To: Jeff Layton , LKML References: <20260304-iino-u64-v3-0-2257ad83d372@kernel.org> Cc: Pavel Machek From: Woody Suwalski Message-ID: Date: Wed, 4 Mar 2026 12:03:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 SeaMonkey/2.53.23 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260304-iino-u64-v3-0-2257ad83d372@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Jeff Layton wrote: > This version squashes all of the format-string changes and the i_ino > type change into the same patch. This results in a giant 600+ line patch > at the end of the series, but it does remain bisectable. Because the > patchset was reorganized (again) some of the R-b's and A-b's have been > dropped. > > The entire pile is in the "iino-u64" branch of my tree, if anyone is > interested in testing this. > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/ > > Original cover letter follows: > > ----------------------8<----------------------- > > Christian said [1] to "just do it" when I proposed this, so here we are! > > For historical reasons, the inode->i_ino field is an unsigned long, > which means that it's 32 bits on 32 bit architectures. This has caused a > number of filesystems to implement hacks to hash a 64-bit identifier > into a 32-bit field, and deprives us of a universal identifier field for > an inode. > > This patchset changes the inode->i_ino field from an unsigned long to a > u64. This shouldn't make any material difference on 64-bit hosts, but > 32-bit hosts will see struct inode grow by at least 4 bytes. This could > have effects on slabcache sizes and field alignment. > > The bulk of the changes are to format strings and tracepoints, since the > kernel itself doesn't care that much about the i_ino field. The first > patch changes some vfs function arguments, so check that one out > carefully. > > With this change, we may be able to shrink some inode structures. For > instance, struct nfs_inode has a fileid field that holds the 64-bit > inode number. With this set of changes, that field could be eliminated. > I'd rather leave that sort of cleanups for later just to keep this > simple. > > Much of this set was generated by LLM, but I attributed it to myself > since I consider this to be in the "menial tasks" category of LLM usage. > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/ > > Signed-off-by: Jeff Layton > Jeff, would you be able to "guestimate" how much extra memory requirement will it impose on 32-bit architectures? Probably nothing critical, but good to know :-) Thanks, Woody