[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241124155955.GD3874922@mit.edu>
Date: Sun, 24 Nov 2024 05:59:55 -1000
From: "Theodore Ts'o" <tytso@....edu>
To: Jinliang Zheng <alexjlzheng@...il.com>
Cc: viro@...iv.linux.org.uk, adobriyan@...il.com, alexjlzheng@...cent.com,
brauner@...nel.org, flyingpeng@...cent.com, jack@...e.cz,
joel.granados@...nel.org, kees@...nel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
mcgrof@...nel.org
Subject: Re: [PATCH 0/6] Maintain the relative size of fs.file-max and
fs.nr_open
On Sun, Nov 24, 2024 at 05:48:13PM +0800, Jinliang Zheng wrote:
> >
> > Short version: there are 3 different notions -
> > 1) file as a collection of data kept by filesystem. Such things as
> > contents, ownership, permissions, timestamps belong there.
> > 2) IO channel used to access one of (1). open(2) creates such;
> > things like current position in file, whether it's read-only or read-write
> > open, etc. belong there. It does not belong to a process - after fork(),
> > ...
>
> I'm sorry that I don't know much about the implementation of UNIX, but
> specific to the implementation of Linux, struct file is more like a
> combination of what you said 1) and 2).
This is incorrect. In Linux (and historical implementations of Unix)
struct file is precisely (2). The struct file has a pointer to a
struct dentry, which in turn has a pointer to a struct inode. So a
struct file *refers* to (1), but it is *not* (1).
- Ted
Powered by blists - more mailing lists