From: Ari Sundholm <ari@tuxera.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] Add checks for hardlinks support.
Date: Wed, 23 Sep 2015 20:00:28 +0300 [thread overview]
Message-ID: <1443027628.5929.46.camel@ari-lenovo> (raw)
In-Reply-To: <20150828042527.GK3902@dastard>
On Fri, 2015-08-28 at 14:25 +1000, Dave Chinner wrote:
> On Thu, Aug 27, 2015 at 01:58:23PM +0300, Ari Sundholm wrote:
> > Do you mean why this patch is needed?
>
> Of course.
>
> Just because the answer migh be obvious to you, it doesn't mean it
> is obvious to anyone else, nor is an empty commit message useful in
> 2-3 years time when someone reads the commit and wonders "why did
> they make that change?"
>
I understand. I had simply thought that a longer explanation was not
necessary in this case. I was wrong.
> > Because there are filesystems that
> > do not support hard links (at least not yet, but may support symlinks)
> > we would like to run xfstests on.
> >
> > I'd be glad to add this explanation and reroll the patches, but I
> > thought this would be obvious from what the patch does.
>
> xfstests doesn't support any filesystems that don't have hardlinks.
> Why we should carry dead code, at minimum, needs explaining and
> discussing.
>
But it does support filesystems which don't support symlinks. What I did
is just an analog of that for hardlinks.
Our company develops filesystem implementations, some of which support
symlinks or hardlinks, but not necessarily both - at least not yet. We
have found xfstests immensely useful in testing both work-in-progress
and established FS implementations and are integrating it as part of our
regular testing framework.
We try to contribute back as much as possible of those things that we
find generally useful. I am strongly of the opinion that this patch *is*
generally useful, as we are far from the only people developing new
filesystems. This is why I do not find this patch to be dead code. The
types of filesystems we work on might not always completely overlap with
the typical features of the filesystems xfstests is usually run on, such
as xfs, ext4 and btrfs, but I think the effort required to support our
filesystems remains small enough to be worth it.
It will definitely not be the end of the world for us if you don't find
this feature generally useful, but we try to upstream as much as
possible of what we think might benefit not only us, but others as well.
> Develop the habits that make you a better software engineer - using
> a "from:" line in patch submissions does not do that.
Will do. I try to learn and hope to keep learning.
Best regards,
Ari Sundholm
ari@tuxera.com
prev parent reply other threads:[~2015-09-23 17:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 9:14 [PATCH 1/2] Add checks for hardlinks support Ari Sundholm
2015-08-27 1:47 ` Dave Chinner
2015-08-27 10:58 ` Ari Sundholm
2015-08-28 4:25 ` Dave Chinner
2015-09-23 17:00 ` Ari Sundholm [this message]
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=1443027628.5929.46.camel@ari-lenovo \
--to=ari@tuxera.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.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