All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-nilfs@vger.kernel.org, xfs@oss.sgi.com,
	Btrfs Developer List <linux-btrfs@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com
Subject: Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag
Date: Thu, 24 Jul 2014 21:22:45 +0200	[thread overview]
Message-ID: <20140724192245.GG1553@suse.cz> (raw)
In-Reply-To: <B58DEEA8-561A-4173-B9F5-528B73E06C6D@dilger.ca>

On Thu, Jul 17, 2014 at 12:07:57AM -0600, Andreas Dilger wrote:
> any progress on this patch series?

I'm sorry I got distracted at the end of year and did not finish the
series.

> I never saw an updated version of this patch series after the last round of
> reviews, but it would be great to move it forward.  I have filefrag patches
> in my e2fsprogs tree waiting for an updated version of your patch.
> 
> I recall the main changes were:
> - add FIEMAP_EXTENT_PHYS_LENGTH flag to indicate if fe_phys_length was valid

fe_phys_length will be always valid, so other the flags are set only if it's
not equal to the logical length.

> - rename fe_length to fe_logi_length and #define fe_length fe_logi_length
> - always fill in fe_phys_length (= fe_logi_length for uncompressed files)
>   and set FIEMAP_EXTENT_PHYS_LENGTH whether the extent is compressed or not

This is my understanding and contradicts the first point.

> - add WARN_ONCE() in fiemap_fill_next_extent() as described below
>
> I don't know if there was any clear statement about whether there should be
> separate FIEMAP_EXTENT_PHYS_LENGTH and FIEMAP_EXTENT_DATA_COMPRESSED flags,
> or if the latter should be implicit?  Probably makes sense to have separate
> flags.  It should be fine to use:
>
> #define FIEMAP_EXTENT_PHYS_LENGTH	0x00000010
> 
> since this flag was never used.

I've kept only FIEMAP_EXTENT_DATA_COMPRESSED, I don't see a need for
FIEMAP_EXTENT_PHYS_LENGTH and this would be yet another flag because the
FIEMAP_EXTENT_DATA_ENCODED is also implied.

I'll send V4, we can discuss the PHYS_LENGTH flag then.

WARNING: multiple messages have this Message-ID (diff)
From: David Sterba <dsterba-AlSwsSmVLrQ@public.gmane.org>
To: Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
Cc: linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org,
	Btrfs Developer List
	<linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Ext4 Developers List
	<linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org
Subject: Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag
Date: Thu, 24 Jul 2014 21:22:45 +0200	[thread overview]
Message-ID: <20140724192245.GG1553@suse.cz> (raw)
In-Reply-To: <B58DEEA8-561A-4173-B9F5-528B73E06C6D-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>

On Thu, Jul 17, 2014 at 12:07:57AM -0600, Andreas Dilger wrote:
> any progress on this patch series?

I'm sorry I got distracted at the end of year and did not finish the
series.

> I never saw an updated version of this patch series after the last round of
> reviews, but it would be great to move it forward.  I have filefrag patches
> in my e2fsprogs tree waiting for an updated version of your patch.
> 
> I recall the main changes were:
> - add FIEMAP_EXTENT_PHYS_LENGTH flag to indicate if fe_phys_length was valid

fe_phys_length will be always valid, so other the flags are set only if it's
not equal to the logical length.

> - rename fe_length to fe_logi_length and #define fe_length fe_logi_length
> - always fill in fe_phys_length (= fe_logi_length for uncompressed files)
>   and set FIEMAP_EXTENT_PHYS_LENGTH whether the extent is compressed or not

This is my understanding and contradicts the first point.

> - add WARN_ONCE() in fiemap_fill_next_extent() as described below
>
> I don't know if there was any clear statement about whether there should be
> separate FIEMAP_EXTENT_PHYS_LENGTH and FIEMAP_EXTENT_DATA_COMPRESSED flags,
> or if the latter should be implicit?  Probably makes sense to have separate
> flags.  It should be fine to use:
>
> #define FIEMAP_EXTENT_PHYS_LENGTH	0x00000010
> 
> since this flag was never used.

I've kept only FIEMAP_EXTENT_DATA_COMPRESSED, I don't see a need for
FIEMAP_EXTENT_PHYS_LENGTH and this would be yet another flag because the
FIEMAP_EXTENT_DATA_ENCODED is also implied.

I'll send V4, we can discuss the PHYS_LENGTH flag then.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: David Sterba <dsterba@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-nilfs@vger.kernel.org, xfs@oss.sgi.com,
	Btrfs Developer List <linux-btrfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com
Subject: Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag
Date: Thu, 24 Jul 2014 21:22:45 +0200	[thread overview]
Message-ID: <20140724192245.GG1553@suse.cz> (raw)
In-Reply-To: <B58DEEA8-561A-4173-B9F5-528B73E06C6D@dilger.ca>

On Thu, Jul 17, 2014 at 12:07:57AM -0600, Andreas Dilger wrote:
> any progress on this patch series?

I'm sorry I got distracted at the end of year and did not finish the
series.

> I never saw an updated version of this patch series after the last round of
> reviews, but it would be great to move it forward.  I have filefrag patches
> in my e2fsprogs tree waiting for an updated version of your patch.
> 
> I recall the main changes were:
> - add FIEMAP_EXTENT_PHYS_LENGTH flag to indicate if fe_phys_length was valid

fe_phys_length will be always valid, so other the flags are set only if it's
not equal to the logical length.

> - rename fe_length to fe_logi_length and #define fe_length fe_logi_length
> - always fill in fe_phys_length (= fe_logi_length for uncompressed files)
>   and set FIEMAP_EXTENT_PHYS_LENGTH whether the extent is compressed or not

This is my understanding and contradicts the first point.

> - add WARN_ONCE() in fiemap_fill_next_extent() as described below
>
> I don't know if there was any clear statement about whether there should be
> separate FIEMAP_EXTENT_PHYS_LENGTH and FIEMAP_EXTENT_DATA_COMPRESSED flags,
> or if the latter should be implicit?  Probably makes sense to have separate
> flags.  It should be fine to use:
>
> #define FIEMAP_EXTENT_PHYS_LENGTH	0x00000010
> 
> since this flag was never used.

I've kept only FIEMAP_EXTENT_DATA_COMPRESSED, I don't see a need for
FIEMAP_EXTENT_PHYS_LENGTH and this would be yet another flag because the
FIEMAP_EXTENT_DATA_ENCODED is also implied.

I'll send V4, we can discuss the PHYS_LENGTH flag then.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: David Sterba <dsterba@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-nilfs@vger.kernel.org, xfs@oss.sgi.com,
	Btrfs Developer List <linux-btrfs@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag
Date: Thu, 24 Jul 2014 21:22:45 +0200	[thread overview]
Message-ID: <20140724192245.GG1553@suse.cz> (raw)
In-Reply-To: <B58DEEA8-561A-4173-B9F5-528B73E06C6D@dilger.ca>

On Thu, Jul 17, 2014 at 12:07:57AM -0600, Andreas Dilger wrote:
> any progress on this patch series?

I'm sorry I got distracted at the end of year and did not finish the
series.

> I never saw an updated version of this patch series after the last round of
> reviews, but it would be great to move it forward.  I have filefrag patches
> in my e2fsprogs tree waiting for an updated version of your patch.
> 
> I recall the main changes were:
> - add FIEMAP_EXTENT_PHYS_LENGTH flag to indicate if fe_phys_length was valid

fe_phys_length will be always valid, so other the flags are set only if it's
not equal to the logical length.

> - rename fe_length to fe_logi_length and #define fe_length fe_logi_length
> - always fill in fe_phys_length (= fe_logi_length for uncompressed files)
>   and set FIEMAP_EXTENT_PHYS_LENGTH whether the extent is compressed or not

This is my understanding and contradicts the first point.

> - add WARN_ONCE() in fiemap_fill_next_extent() as described below
>
> I don't know if there was any clear statement about whether there should be
> separate FIEMAP_EXTENT_PHYS_LENGTH and FIEMAP_EXTENT_DATA_COMPRESSED flags,
> or if the latter should be implicit?  Probably makes sense to have separate
> flags.  It should be fine to use:
>
> #define FIEMAP_EXTENT_PHYS_LENGTH	0x00000010
> 
> since this flag was never used.

I've kept only FIEMAP_EXTENT_DATA_COMPRESSED, I don't see a need for
FIEMAP_EXTENT_PHYS_LENGTH and this would be yet another flag because the
FIEMAP_EXTENT_DATA_ENCODED is also implied.

I'll send V4, we can discuss the PHYS_LENGTH flag then.

  reply	other threads:[~2014-07-24 19:22 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 15:25 [PATCH 0/4 v3] fiemap: introduce EXTENT_DATA_COMPRESSED flag David Sterba
2013-12-12 15:26 ` [Ocfs2-devel] " David Sterba
2013-12-12 15:25 ` David Sterba
2013-12-12 15:25 ` [PATCH 1/4 v3] fiemap: fix comment at EXTENT_DATA_ENCRYPTED David Sterba
2013-12-12 15:25 ` [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag David Sterba
2013-12-12 15:26   ` [Ocfs2-devel] " David Sterba
2013-12-12 15:25   ` David Sterba
2013-12-12 23:24   ` Dave Chinner
2013-12-12 23:25     ` [Ocfs2-devel] " Dave Chinner
2013-12-12 23:24     ` Dave Chinner
2013-12-12 23:24     ` Dave Chinner
2013-12-13  0:02     ` Andreas Dilger
2013-12-13  0:02       ` [Ocfs2-devel] " Andreas Dilger
2013-12-13  0:02       ` Andreas Dilger
2013-12-13  0:02       ` Andreas Dilger
2013-12-13  1:22       ` Dave Chinner
2013-12-13  1:23         ` [Ocfs2-devel] " Dave Chinner
2013-12-13  1:22         ` Dave Chinner
2013-12-16 16:49         ` David Sterba
2013-12-16 16:49           ` [Ocfs2-devel] " David Sterba
2013-12-16 16:49           ` David Sterba
2014-07-17  6:07       ` Andreas Dilger
2014-07-17  6:07         ` [Ocfs2-devel] " Andreas Dilger
2014-07-17  6:07         ` Andreas Dilger
2014-07-17  6:07         ` Andreas Dilger
2014-07-24 19:22         ` David Sterba [this message]
2014-07-24 19:22           ` [Ocfs2-devel] " David Sterba
2014-07-24 19:22           ` David Sterba
2014-07-24 19:22           ` David Sterba
2014-07-24 22:34           ` Andreas Dilger
2014-07-24 22:34             ` [Ocfs2-devel] " Andreas Dilger
2014-07-24 22:34             ` Andreas Dilger
2014-07-25  6:20             ` Rohan Puri
2014-07-25  6:20               ` [Ocfs2-devel] " Rohan Puri
2014-07-25  6:20               ` Rohan Puri
2014-07-25  6:20               ` Rohan Puri
2014-07-28 16:49             ` [Ocfs2-devel] " David Sterba
2014-07-28 16:49               ` David Sterba
2013-12-13 11:06     ` Christoph Hellwig
2013-12-13 11:06       ` [Ocfs2-devel] " Christoph Hellwig
2013-12-13 11:06       ` Christoph Hellwig
2013-12-12 15:26 ` [PATCH 3/4 v3] btrfs: set FIEMAP_EXTENT_DATA_COMPRESSED for compressed extents David Sterba
2013-12-12 22:20   ` Andreas Dilger
2013-12-12 15:26 ` [PATCH 4/4 v3] Documentation/fiemap: Document the DATA_COMPRESSED flag David Sterba
2013-12-12 22:22 ` [PATCH 0/4 v3] fiemap: introduce EXTENT_DATA_COMPRESSED flag Andreas Dilger
2013-12-12 22:22   ` [Ocfs2-devel] " Andreas Dilger
2013-12-12 22:22   ` Andreas Dilger

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=20140724192245.GG1553@suse.cz \
    --to=dsterba@suse.cz \
    --cc=adilger@dilger.ca \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.