From: Badari Pulavarty <pbadari@us.ibm.com>
To: "Ragnar Kjørstad" <kernel@ragnark.vestdata.no>
Cc: Pavel Machek <pavel@suse.cz>, Andrew Morton <akpm@osdl.org>,
andrea@suse.de, hugh@veritas.com,
lkml <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC] sys_punchhole()
Date: Fri, 18 Nov 2005 08:54:53 -0800 [thread overview]
Message-ID: <1132332893.24066.159.camel@localhost.localdomain> (raw)
In-Reply-To: <20051118164227.GA14697@vestdata.no>
On Fri, 2005-11-18 at 17:42 +0100, Ragnar Kjørstad wrote:
> On Sun, Nov 13, 2005 at 03:09:06PM +0000, Pavel Machek wrote:
> > > > We discussed this in madvise(REMOVE) thread - to add support
> > > > for sys_punchhole(fd, offset, len) to complete the functionality
> > > > (in the future).
> > > >
> > > > http://marc.theaimsgroup.com/?l=linux-mm&m=113036713810002&w=2
> > > >
> > > > What I am wondering is, should I invest time now to do it ?
> > >
> > > I haven't even heard anyone mention a need for this in the past 1-2 years.
> >
> > Some database people wanted it maybe month ago. It was replaced by some
> > madvise hack...
>
>
> sys_punchhole is also potentially very useful for Hirarchial Storage
> Management. (Holes are typically used for data that have been migrated
> to tape).
I agree. But I am not interested in adding whole lot of complexity in
the kernel, just because some "potential" use for this. I want to know,
if people/products which really really need this feature and their
requirements, before I go down that path.
For that matter, HSM folks really care about DMAPI. But I never got
them to explicitly tell me, what is the most minimum subset interfaces
they *absolutely* need (and why) in the whole DMAPI specs :( I always
hear complaints about not having DMAPI.
Thanks,
Badari
WARNING: multiple messages have this Message-ID (diff)
From: Badari Pulavarty <pbadari@us.ibm.com>
To: "Ragnar Kjørstad" <kernel@ragnark.vestdata.no>
Cc: Pavel Machek <pavel@suse.cz>, Andrew Morton <akpm@osdl.org>,
andrea@suse.de, hugh@veritas.com,
lkml <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC] sys_punchhole()
Date: Fri, 18 Nov 2005 08:54:53 -0800 [thread overview]
Message-ID: <1132332893.24066.159.camel@localhost.localdomain> (raw)
In-Reply-To: <20051118164227.GA14697@vestdata.no>
On Fri, 2005-11-18 at 17:42 +0100, Ragnar KjA,rstad wrote:
> On Sun, Nov 13, 2005 at 03:09:06PM +0000, Pavel Machek wrote:
> > > > We discussed this in madvise(REMOVE) thread - to add support
> > > > for sys_punchhole(fd, offset, len) to complete the functionality
> > > > (in the future).
> > > >
> > > > http://marc.theaimsgroup.com/?l=linux-mm&m=113036713810002&w=2
> > > >
> > > > What I am wondering is, should I invest time now to do it ?
> > >
> > > I haven't even heard anyone mention a need for this in the past 1-2 years.
> >
> > Some database people wanted it maybe month ago. It was replaced by some
> > madvise hack...
>
>
> sys_punchhole is also potentially very useful for Hirarchial Storage
> Management. (Holes are typically used for data that have been migrated
> to tape).
I agree. But I am not interested in adding whole lot of complexity in
the kernel, just because some "potential" use for this. I want to know,
if people/products which really really need this feature and their
requirements, before I go down that path.
For that matter, HSM folks really care about DMAPI. But I never got
them to explicitly tell me, what is the most minimum subset interfaces
they *absolutely* need (and why) in the whole DMAPI specs :( I always
hear complaints about not having DMAPI.
Thanks,
Badari
--
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:[~2005-11-18 16:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 23:23 [RFC] sys_punchhole() Badari Pulavarty
2005-11-10 23:23 ` Badari Pulavarty
2005-11-10 23:32 ` Andrew Morton
2005-11-10 23:32 ` Andrew Morton
2005-11-10 23:41 ` Badari Pulavarty
2005-11-10 23:41 ` Badari Pulavarty
2005-11-10 23:55 ` Anton Altaparmakov
2005-11-10 23:55 ` Anton Altaparmakov
2005-11-11 8:25 ` Ingo Oeser
2005-11-11 19:07 ` Christoph Lameter
2005-11-11 19:07 ` Christoph Lameter
2005-11-16 12:08 ` Rob Landley
2005-11-16 12:08 ` Rob Landley
2005-11-16 12:20 ` Andrea Arcangeli
2005-11-16 12:20 ` Andrea Arcangeli
2005-11-13 15:09 ` Pavel Machek
2005-11-13 15:09 ` Pavel Machek
2005-11-16 22:01 ` Badari Pulavarty
2005-11-16 22:01 ` Badari Pulavarty
2005-11-16 23:37 ` Ric Wheeler
2005-11-16 23:37 ` Ric Wheeler
2005-11-21 6:46 ` Rob Landley
2005-11-21 6:46 ` Rob Landley
2005-11-18 16:42 ` Ragnar Kjørstad
2005-11-18 16:42 ` Ragnar Kjørstad
2005-11-18 16:54 ` Badari Pulavarty [this message]
2005-11-18 16:54 ` Badari Pulavarty
2005-11-11 5:18 ` Arjan van de Ven
2005-11-11 5:18 ` Arjan van de Ven
2005-11-13 6:11 ` H. Peter Anvin
2005-11-16 16:05 ` Badari Pulavarty
2005-11-16 16:05 ` Badari Pulavarty
2005-11-16 16:38 ` Anton Altaparmakov
2005-11-16 16:38 ` Anton Altaparmakov
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=1132332893.24066.159.camel@localhost.localdomain \
--to=pbadari@us.ibm.com \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=hugh@veritas.com \
--cc=kernel@ragnark.vestdata.no \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pavel@suse.cz \
/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.