[GIT PULL] zonefs changes for 5.19-rc1

[GIT PULL] zonefs changes for 5.19-rc1

[Damien Le Moal]

Linus,

The following changes since commit 19139539207934aef6335bdef09c9e4bd70d1808:

  zonefs: Fix management of open zones (2022-04-21 08:37:35 +0900)

are available in the Git repository at:

  ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs tags/zonefs-5.19-rc1

for you to fetch changes up to 31a644b3c2ae6d0c47e84614ded3ce9bef1adb7a:

  documentation: zonefs: Document sysfs attributes (2022-04-26 14:53:06 +0900)

Note: I made a mistake during this PR preparation and inadvertantly deleted the
for-5.19 branch used for this PR. I recreated it and prepared the PR using this
newly pushed for-5.19 branch. All patches have been in linux-next for a while.
I hope this does not trigger any problem on your end.

----------------------------------------------------------------
zonefs changes for 5.19-rc1

This set of patches improve zonefs open sequential file accounting and
adds accounting for active sequential files to allow the user to handle
the maximum number of active zones of an NVMe ZNS drive. sysfs
attributes for both open and active sequential files are also added to
facilitate access to this information from applications without
resorting to inspecting the block device limits.

----------------------------------------------------------------
Damien Le Moal (6):
      zonefs: Rename super block information fields
      zonefs: Always do seq file write open accounting
      zonefs: Export open zone resource information through sysfs
      zonefs: Add active seq file accounting
      documentation: zonefs: Cleanup the mount options section
      documentation: zonefs: Document sysfs attributes

 Documentation/filesystems/zonefs.rst |  52 +++++++++-
 fs/zonefs/Makefile                   |   2 +-
 fs/zonefs/super.c                    | 186 ++++++++++++++++++++++++++---------
 fs/zonefs/sysfs.c                    | 139 ++++++++++++++++++++++++++
 fs/zonefs/zonefs.h                   |  18 +++-
 5 files changed, 344 insertions(+), 53 deletions(-)
 create mode 100644 fs/zonefs/sysfs.c

Re: [GIT PULL] zonefs changes for 5.19-rc1

[Linus Torvalds]

On Sun, May 22, 2022 at 10:01 PM Damien Le Moal
<damien.lemoal@opensource.wdc.com> wrote:
>
> Note: I made a mistake during this PR preparation and inadvertantly deleted the
> for-5.19 branch used for this PR. I recreated it and prepared the PR using this
> newly pushed for-5.19 branch. All patches have been in linux-next for a while.
> I hope this does not trigger any problem on your end.

Grr.

That seems to be the cause of repeated commits, which in turn then
caused conflicts because you had further changes.

IOW, I already had gotten

  zonefs: Fix management of open zones
  zonefs: Clear inode information flags on inode creation

from the block tree (your commits), and your branch now had different
copies of those commits.

And you don't actually list those commits, which makes me think that
you then did some manual editing of the pull request.

The duplicate commits with identical contents then caused commit
87c9ce3ffec9 ("zonefs: Add active seq file accounting") to show as a
conflict, because the different branches did *some* things the same,
but then that commit added other changes.

And honestly, I think that commit is buggy.

In particular, notice how the locking changes in that commit means
that zonefs_init_file_inode() now always returns 0, even if
zonefs_zone_mgmt() failed with an error.

The error cause it to skip "zonefs_account_active()", but then it
returns success anyway.

Was that really intentional?

I've merged this - with that apparent bug and all - because maybe it
*was* intentional. But please double-check and confirm that you really
intended zonefs_init_file_inode() to always return success, unlike the
old behavior.

                  Linus

Re: [GIT PULL] zonefs changes for 5.19-rc1

[pr-tracker-bot]

The pull request you sent on Mon, 23 May 2022 14:01:44 +0900:

> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs tags/zonefs-5.19-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/140e40e39a29c7dbc188d9b43831c3d5e089c960

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] zonefs changes for 5.19-rc1

[Damien Le Moal]

On 5/24/22 06:37, Linus Torvalds wrote:
> On Sun, May 22, 2022 at 10:01 PM Damien Le Moal
> <damien.lemoal@opensource.wdc.com> wrote:
>>
>> Note: I made a mistake during this PR preparation and inadvertantly deleted the
>> for-5.19 branch used for this PR. I recreated it and prepared the PR using this
>> newly pushed for-5.19 branch. All patches have been in linux-next for a while.
>> I hope this does not trigger any problem on your end.
> 
> Grr.
> 
> That seems to be the cause of repeated commits, which in turn then
> caused conflicts because you had further changes.
> 
> IOW, I already had gotten
> 
>   zonefs: Fix management of open zones
>   zonefs: Clear inode information flags on inode creation
> 
> from the block tree (your commits), and your branch now had different
> copies of those commits.
> 
> And you don't actually list those commits, which makes me think that
> you then did some manual editing of the pull request.

Yes I did. I really messed up. My apologies about that.

> 
> The duplicate commits with identical contents then caused commit
> 87c9ce3ffec9 ("zonefs: Add active seq file accounting") to show as a
> conflict, because the different branches did *some* things the same,
> but then that commit added other changes.
> 
> And honestly, I think that commit is buggy.
> 
> In particular, notice how the locking changes in that commit means
> that zonefs_init_file_inode() now always returns 0, even if
> zonefs_zone_mgmt() failed with an error.
> 
> The error cause it to skip "zonefs_account_active()", but then it
> returns success anyway.
> 
> Was that really intentional?

Absolutely not. That is definitely a bug. Will send a fix for that.
Thank you for catching this.

> 
> I've merged this - with that apparent bug and all - because maybe it
> *was* intentional. But please double-check and confirm that you really
> intended zonefs_init_file_inode() to always return success, unlike the
> old behavior.
> 
>                   Linus


-- 
Damien Le Moal
Western Digital Research