All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] tmpfs: revert SEEK_DATA and SEEK_HOLE
Date: Tue, 17 Jul 2012 14:15:42 +0800	[thread overview]
Message-ID: <5005030E.8050509@oracle.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1207160206460.4082@eggly.anvils>

On 07/16/2012 05:28 PM, Hugh Dickins wrote:

> On Thu, 12 Jul 2012, Jeff Liu wrote:
>> On 07/12/2012 07:01 AM, Dave Chinner wrote:
>>> On Wed, Jul 11, 2012 at 11:55:34AM -0700, Hugh Dickins wrote:
>>>>
>>>> But your vote would count for a lot more if you know of some app which
>>>> would really benefit from this functionality in tmpfs: I've heard of none.
>>>
>>> So what? I've heard of no apps that use this functionality on XFS,
>>> either, but I have heard of a lot of people asking for it to be
>>> implemented over the past couple of years so they can use it.
>>> There's been patches written to make coreutils (cp) make use of it
>>> instead of parsing FIEMAP output to find holes, though I don't know
>>> if that's gone beyond more than "here's some patches"...
>>
>> Yes, for apps, cp(1) will make use of it to replace the old FIEMAP for efficient sparse file copy.
>> I have implemented an extent-scan module to coreutils a few years ago,
>> http://fossies.org/dox/coreutils-8.17/extent-scan_8c_source.html
> 
> Thanks for confirming Dave's pointer to cp.
> 
> Of course, tmpfs has never supported FIBMAP or FIEMAP;
> but SEEK_DATA and SEEK_HOLE do fit it much more naturally.
> 
>>
>> It does extent scan through FIEMAP, however, SEEK_DATA/SEEK_HOLE is more convenient and easy to use
>> considering the call interface.  So FIEMAP will be replaced by SEEK_XXX once it got supported by EXT4.
>>
>> Moreover, I have discussed with Jim who is the coreutils maintainer previously, He would like to post
>> extent-scan module to Gnulib so that other GNU utilities which are relied on Gnulib might be a potential
>> user of it, at least, GNU tar will definitely need it for sparse file backup.
> 
> Thanks for the info.  I confess I'm not hugely swayed by cp and sparse
> file archive arguments - I doubt many people care, and I doubt those who
> do care are using tmpfs for them.
> 
> But my doubts are just ignorance.  I was hoping to hear, not that we have
> tools to copy sparse files efficiently (umm, over the network?), but
> what apps are actually working live with those sparse files on tmpfs,
> and now need to seek around them.  Some math or physics applications?
> 
>>>
>>> Besides, given that you can punch holes in tmpfs files, it seems
>>> strange to then say "we don't need a method of skipping holes to
>>> find data quickly"....
>>
>> So its deserve to keep this feature working on tmpfs considering hole punch. :)
> 
> Well, thank you, as I said earlier I am on both sides of the argument.
> (And feel uncomfortably like a prima donna waiting in the wings until
> the audience has shouted long enough for the encore.)

Oh, sorry, I missed you response to Dave before.

> 
> It's now taken out of 3.5, but we can bring it back when there's more
> demand.

Yep. :)

Thanks,
-Jeff

> Your extent-scan is itself waiting for ext4 to support it:
> maybe get noisy at me when that's imminent.

> 
> Hugh
> 
>>
>> Thanks,
>> -Jeff
>>
>>>
>>> Besides, seek-hole/data is still shiny new and lots of developers
>>> aren't even aware of it's presence in recent kernels. Removing new
>>> functionality saying "no-one is using it" is like smashing the egg
>>> before the chicken hatches (or is it cutting of the chickes's head
>>> before it lays the egg?).
>>>
>>> Cheers,
>>>
>>> Dave.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



WARNING: multiple messages have this Message-ID (diff)
From: Jeff Liu <jeff.liu@oracle.com>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] tmpfs: revert SEEK_DATA and SEEK_HOLE
Date: Tue, 17 Jul 2012 14:15:42 +0800	[thread overview]
Message-ID: <5005030E.8050509@oracle.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1207160206460.4082@eggly.anvils>

On 07/16/2012 05:28 PM, Hugh Dickins wrote:

> On Thu, 12 Jul 2012, Jeff Liu wrote:
>> On 07/12/2012 07:01 AM, Dave Chinner wrote:
>>> On Wed, Jul 11, 2012 at 11:55:34AM -0700, Hugh Dickins wrote:
>>>>
>>>> But your vote would count for a lot more if you know of some app which
>>>> would really benefit from this functionality in tmpfs: I've heard of none.
>>>
>>> So what? I've heard of no apps that use this functionality on XFS,
>>> either, but I have heard of a lot of people asking for it to be
>>> implemented over the past couple of years so they can use it.
>>> There's been patches written to make coreutils (cp) make use of it
>>> instead of parsing FIEMAP output to find holes, though I don't know
>>> if that's gone beyond more than "here's some patches"...
>>
>> Yes, for apps, cp(1) will make use of it to replace the old FIEMAP for efficient sparse file copy.
>> I have implemented an extent-scan module to coreutils a few years ago,
>> http://fossies.org/dox/coreutils-8.17/extent-scan_8c_source.html
> 
> Thanks for confirming Dave's pointer to cp.
> 
> Of course, tmpfs has never supported FIBMAP or FIEMAP;
> but SEEK_DATA and SEEK_HOLE do fit it much more naturally.
> 
>>
>> It does extent scan through FIEMAP, however, SEEK_DATA/SEEK_HOLE is more convenient and easy to use
>> considering the call interface.  So FIEMAP will be replaced by SEEK_XXX once it got supported by EXT4.
>>
>> Moreover, I have discussed with Jim who is the coreutils maintainer previously, He would like to post
>> extent-scan module to Gnulib so that other GNU utilities which are relied on Gnulib might be a potential
>> user of it, at least, GNU tar will definitely need it for sparse file backup.
> 
> Thanks for the info.  I confess I'm not hugely swayed by cp and sparse
> file archive arguments - I doubt many people care, and I doubt those who
> do care are using tmpfs for them.
> 
> But my doubts are just ignorance.  I was hoping to hear, not that we have
> tools to copy sparse files efficiently (umm, over the network?), but
> what apps are actually working live with those sparse files on tmpfs,
> and now need to seek around them.  Some math or physics applications?
> 
>>>
>>> Besides, given that you can punch holes in tmpfs files, it seems
>>> strange to then say "we don't need a method of skipping holes to
>>> find data quickly"....
>>
>> So its deserve to keep this feature working on tmpfs considering hole punch. :)
> 
> Well, thank you, as I said earlier I am on both sides of the argument.
> (And feel uncomfortably like a prima donna waiting in the wings until
> the audience has shouted long enough for the encore.)

Oh, sorry, I missed you response to Dave before.

> 
> It's now taken out of 3.5, but we can bring it back when there's more
> demand.

Yep. :)

Thanks,
-Jeff

> Your extent-scan is itself waiting for ext4 to support it:
> maybe get noisy at me when that's imminent.

> 
> Hugh
> 
>>
>> Thanks,
>> -Jeff
>>
>>>
>>> Besides, seek-hole/data is still shiny new and lots of developers
>>> aren't even aware of it's presence in recent kernels. Removing new
>>> functionality saying "no-one is using it" is like smashing the egg
>>> before the chicken hatches (or is it cutting of the chickes's head
>>> before it lays the egg?).
>>>
>>> Cheers,
>>>
>>> Dave.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-07-17  6:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 22:35 [PATCH 0/3] shmem/tmpfs: three late patches Hugh Dickins
2012-07-09 22:35 ` Hugh Dickins
2012-07-09 22:41 ` [PATCH 1/3] tmpfs: revert SEEK_DATA and SEEK_HOLE Hugh Dickins
2012-07-09 22:41   ` Hugh Dickins
2012-07-11  6:07   ` Cong Wang
2012-07-11  6:07     ` Cong Wang
2012-07-11 18:55     ` Hugh Dickins
2012-07-11 18:55       ` Hugh Dickins
2012-07-11 23:01       ` Dave Chinner
2012-07-11 23:01         ` Dave Chinner
2012-07-12  2:50         ` Hugh Dickins
2012-07-12  2:50           ` Hugh Dickins
2012-07-12  3:21         ` Jeff Liu
2012-07-12  3:21           ` Jeff Liu
2012-07-16  9:28           ` Hugh Dickins
2012-07-16  9:28             ` Hugh Dickins
2012-07-17  6:15             ` Jeff Liu [this message]
2012-07-17  6:15               ` Jeff Liu
2012-07-31 14:30             ` Jim Meyering
2012-07-31 14:42               ` Jim Meyering
2012-08-08  2:08               ` Hugh Dickins
2012-08-14 17:03                 ` Paul Eggert
2012-07-09 22:44 ` [PATCH 2/3] shmem: fix negative rss in memcg memory.stat Hugh Dickins
2012-07-09 22:44   ` Hugh Dickins
2012-07-10 12:41   ` Johannes Weiner
2012-07-10 12:41     ` Johannes Weiner
2012-07-11 18:15     ` Hugh Dickins
2012-07-11 18:15       ` Hugh Dickins
2012-07-09 22:46 ` [PATCH 3/3] shmem: cleanup shmem_add_to_page_cache Hugh Dickins
2012-07-09 22:46   ` Hugh Dickins
2012-07-10 13:01   ` Johannes Weiner
2012-07-10 13:01     ` Johannes Weiner
2012-07-09 23:39 ` [PATCH 0/3] shmem/tmpfs: three late patches Andrew Morton
2012-07-09 23:39   ` Andrew Morton

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=5005030E.8050509@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xiyou.wangcong@gmail.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.