From: Hugh Dickins <hughd@google.com> To: Dave Chinner <david@fromorbit.com> Cc: 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: Wed, 11 Jul 2012 19:50:53 -0700 (PDT) [thread overview] Message-ID: <alpine.LSU.2.00.1207111920210.1455@eggly.anvils> (raw) In-Reply-To: <20120711230122.GZ19223@dastard> On Thu, 12 Jul 2012, Dave Chinner wrote: > On Wed, Jul 11, 2012 at 11:55:34AM -0700, Hugh Dickins wrote: > > On Wed, 11 Jul 2012, Cong Wang wrote: > > > > > > If you don't have burden to maintain it, I'd prefer to leave as it is, > > > I don't think 752-bytes is the reason we revert it. > > > > Thank you, your vote has been counted ;) > > and I'll be glad if yours stimulates some agreement or disagreement. > > > > 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. I'd certainly not ask you to remove your support for it from XFS: nobody would call XFS a minimal filesystem. But tmpfs has a tradition and a duty to keep fairly small: it needs to be useful, but it shouldn't be carrying unused baggage. > 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".... > > 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".... tmpfs has been punching holes (via MADV_REMOVE) since 2.6.16 (and that wasn't added on my whim, IBM wanted and did it). But I haven't heard of anybody asking for a method of skipping them in six years. > > 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?). (You remind me of my chicken-and-egg sandwiches - you can't get them, you see, it's chicken and egg.) I'm not trying to remove SEEK_HOLE/SEEK_DATA support from the kernel: I'm just saying that nobody has yet made the case for their usefulness in tmpfs, so they're better removed from it before v3.5 is released. Once we see how useful they have become in the grown-up filesystems, or someone shows how useful they can be on tmpfs, then we reinstate. Of course, I'm on both sides of this argument: I wrote that code, I like it, I'll be glad to put it back when it's useful to someone. Hugh
WARNING: multiple messages have this Message-ID (diff)
From: Hugh Dickins <hughd@google.com> To: Dave Chinner <david@fromorbit.com> Cc: 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: Wed, 11 Jul 2012 19:50:53 -0700 (PDT) [thread overview] Message-ID: <alpine.LSU.2.00.1207111920210.1455@eggly.anvils> (raw) In-Reply-To: <20120711230122.GZ19223@dastard> On Thu, 12 Jul 2012, Dave Chinner wrote: > On Wed, Jul 11, 2012 at 11:55:34AM -0700, Hugh Dickins wrote: > > On Wed, 11 Jul 2012, Cong Wang wrote: > > > > > > If you don't have burden to maintain it, I'd prefer to leave as it is, > > > I don't think 752-bytes is the reason we revert it. > > > > Thank you, your vote has been counted ;) > > and I'll be glad if yours stimulates some agreement or disagreement. > > > > 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. I'd certainly not ask you to remove your support for it from XFS: nobody would call XFS a minimal filesystem. But tmpfs has a tradition and a duty to keep fairly small: it needs to be useful, but it shouldn't be carrying unused baggage. > 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".... > > 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".... tmpfs has been punching holes (via MADV_REMOVE) since 2.6.16 (and that wasn't added on my whim, IBM wanted and did it). But I haven't heard of anybody asking for a method of skipping them in six years. > > 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?). (You remind me of my chicken-and-egg sandwiches - you can't get them, you see, it's chicken and egg.) I'm not trying to remove SEEK_HOLE/SEEK_DATA support from the kernel: I'm just saying that nobody has yet made the case for their usefulness in tmpfs, so they're better removed from it before v3.5 is released. Once we see how useful they have become in the grown-up filesystems, or someone shows how useful they can be on tmpfs, then we reinstate. Of course, I'm on both sides of this argument: I wrote that code, I like it, I'll be glad to put it back when it's useful to someone. Hugh -- 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>
next prev parent reply other threads:[~2012-07-12 2:51 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 [this message] 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 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=alpine.LSU.2.00.1207111920210.1455@eggly.anvils \ --to=hughd@google.com \ --cc=david@fromorbit.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: linkBe 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.