linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	jfs-discussion@lists.sourceforge.net,
	Matthew Wilcox <willy@infradead.org>,
	"linux-ext4@vger.kernel.org Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [Jfs-discussion] [RFC PATCH 0/9] Convert JFS to use iomap
Date: Tue, 31 May 2022 08:51:40 -0500	[thread overview]
Message-ID: <b3b1a6a0-f6fe-b054-c3ad-b6ab0f62314c@oracle.com> (raw)
In-Reply-To: <20220529235122.GJ3923443@dread.disaster.area>

On 5/29/22 6:51PM, Dave Chinner wrote:
> On Sat, May 28, 2022 at 02:59:31PM -0400, Theodore Ts'o wrote:
>> +linux-ext4
>>
>> On Sat, May 28, 2022 at 03:36:39PM +1000, Dave Chinner wrote:
>>> The other filesystem that uses nobh is the standalone ext2
>>> filesystem that nobody uses anymore as the ext4 module provides ext2
>>> functionality for distros these days. Hence there's an argument that
>>> can be made for removing fs/ext2 as well. In which case, the whole
>>> nobh problem goes away by deprecating and removing both the
>>> filesysetms that use that infrastructure in 2 years time....
>>
>> This got brought up at this past week's ext4 video chat, where Willy
>> asked Jan (who has been maintaining ext2) whether he would be open to
>> converting ext2 to use iomap.  The answer was yes.  So once jfs and
>> ext2 are converted, we'll be able to nuke the nobh code.
>>
>>  From Willy's comments on the video chat, my understanding is that jfs
>> was even simpler to convert that ext2, and this allows us to remove
>> the nobh infrastructure without asking the question about whether it's
>> time to remove jfs.
> 
> I disagree there - if we are changing code that has been unchanged
> for a decade or more, there are very few users of that code, and
> there's a good chance that data corruption regressions will result
> from the changes being proposed, then asking the question "why take
> the risk" is very pertinent.
> 
> "Just because we can" isn't a good answer. The best code is code we
> don't have to write and maintain. If it's a burden to maintain and a
> barrier to progress, then we should seriously be considering
> removing it, not trying to maintain the fiction that it's a viable
> supported production quality filesystem that people can rely on....

I'm onboard to sunsetting jfs. I don't know of anyone that is currently 
using it in any serious way. (jfs-discussion group, this is a good time 
to chime in if you feel differently.)

On the other hand, because it is not being used in an any 
mission-critical way, it may be a good filesystem to do an early 
conversion on to see what issues might come up. Unfortunately, I've got 
a really busy two months in front of me and won't be much help.

Thanks,
Shaggy

> 
>>>> We also need to convert more filesystems to use iomap.
>>>
>>> We also need to deprecate and remove more largely unmaintained and
>>> unused filesystems. :)
>>
>> Well, Dave Kleikamp is still around and sends jfs pull requests from
>> time to time, and so it's not as unmaintained as, say, fs/adfs,
>> fs/freevxs, fs/hpfs, fs/minix, and fs/sysv.
> 
> Yes, but the changes that have been made over the past decade are
> all small and minor - there's been no feature work, no cleanup work,
> no attempt to update core infrastructure, etc. There's beeen no
> serious attempts to modernise or update the code for a decade...
> 
>> As regards to minixfs, I'd argue that ext2 is a better reference file
>> system than minixfs.  So..... are we ready to remove minixfs?  I could
>> easily see that some folks might still have sentimental attachment to
>> minixfs.  :-)
> 
> AFAIC, yes, minixfs and and those other ones should have been
> deprecated long ago....
> 
> Cheers,
> 
> Dave.

  reply	other threads:[~2022-05-31 13:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:29 [RFC PATCH 0/9] Convert JFS to use iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 1/9] IOMAP_DIO_NOSYNC Matthew Wilcox (Oracle)
2022-05-27  5:35   ` Christoph Hellwig
2022-05-27 13:20     ` Matthew Wilcox
2022-05-26 19:29 ` [RFC PATCH 2/9] jfs: Add jfs_iomap_begin() Matthew Wilcox (Oracle)
2022-05-27  5:41   ` Christoph Hellwig
2022-05-27 13:45     ` Matthew Wilcox
2022-05-27 14:58       ` [Jfs-discussion] " Dave Kleikamp
2022-05-26 19:29 ` [RFC PATCH 3/9] jfs: Convert direct_IO read support to use iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 4/9] jfs: Convert direct_IO write " Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 5/9] jfs: Remove old direct_IO support Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 6/9] jfs: Handle bmap with iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 7/9] jfs: Read quota through the page cache Matthew Wilcox (Oracle)
2022-05-27  5:43   ` Christoph Hellwig
2022-05-27 13:56     ` Matthew Wilcox
2022-06-03 14:40     ` generic_quota_read Matthew Wilcox
2022-06-06  7:37       ` generic_quota_read Jan Kara
2022-05-26 19:29 ` [RFC PATCH 8/9] jfs: Write quota through the page cache Matthew Wilcox (Oracle)
2022-05-27  5:46   ` Christoph Hellwig
2022-05-26 19:29 ` [RFC PATCH 9/9] jfs: Convert buffered IO paths to iomap Matthew Wilcox (Oracle)
2022-05-28  0:02 ` [RFC PATCH 0/9] Convert JFS to use iomap Dave Chinner
2022-05-28  2:15   ` Matthew Wilcox
2022-05-28  5:36     ` Dave Chinner
2022-05-28 18:59       ` Theodore Ts'o
2022-05-29 23:51         ` Dave Chinner
2022-05-31 13:51           ` Dave Kleikamp [this message]
2022-05-31 15:31             ` [Jfs-discussion] " Matthew Wilcox
2022-05-31 15:56               ` Dave Kleikamp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3b1a6a0-f6fe-b054-c3ad-b6ab0f62314c@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).