From: Pavel Machek <pavel@ucw.cz>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "Andreas Dilger" <adilger@dilger.ca>,
"Jörn Engel" <joern@logfs.org>,
"Andy Lutomirski" <luto@amacapital.net>,
"Zach Brown" <zab@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Ric Wheeler" <rwheeler@redhat.com>,
"Linux FS Devel" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Chris L. Mason" <clmason@fusionio.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Alexander Viro" <aviro@redhat.com>,
"Martin K. Petersen" <mkp@mkp.net>,
"Hannes Reinecke" <hare@suse.de>,
"Joel Becker" <jlbec@evilplan.org>
Subject: Re: New copyfile system call - discuss before LSF?
Date: Sun, 31 Mar 2013 09:36:07 +0200 [thread overview]
Message-ID: <20130331073604.GA13159@amd.pavel.ucw.cz> (raw)
In-Reply-To: <925D663D-D8F8-4297-A642-33C732354701@netapp.com>
Hi!
> >>> Hmm, really? AFAICT it would be simple to provide an
> >>> open_deleted_file("directory") syscall. You'd open_deleted_file(),
> >>> copy source file into it, then fsync(), then link it into filesystem.
> >>>
> >>> That should have atomicity properties reflected.
> >>
> >> Actually, the open_deleted_file() syscall is quite useful for many
> >> different things all by itself. Lots of applications need to create
> >> temporary files that are unlinked at application failure (without a
> >> race if app crashes after creating the file, but before unlinking).
> >> It also avoids exposing temporary files into the namespace if other
> >> applications are accessing the directory.
> >
> > Hmm. open_deleted_file() will still need to get a directory... so it
> > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
> > be acceptable interface?
>
> ...and what's the big plan to make this work on anything other than ext4 and btrfs?
Deleted but open files are from original unix, so it should work on
anything unixy (minix, ext, ext2, ...).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2013-03-31 7:36 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 11:37 New copyfile system call - discuss before LSF? Ric Wheeler
2013-02-21 13:37 ` Hannes Reinecke
2013-02-21 13:51 ` Myklebust, Trond
2013-02-21 14:57 ` Ric Wheeler
2013-02-21 16:36 ` Andreas Dilger
2013-02-21 20:00 ` Paolo Bonzini
2013-02-21 20:50 ` Myklebust, Trond
2013-02-21 22:24 ` Zach Brown
2013-02-22 1:29 ` Myklebust, Trond
2013-02-23 0:32 ` Eric Wong
2013-03-30 19:45 ` Pavel Machek
2013-03-31 21:23 ` Eric Wong
2013-02-22 9:47 ` Paolo Bonzini
2013-02-22 9:52 ` Ric Wheeler
2013-02-22 18:22 ` Zach Brown
2013-02-22 22:48 ` Myklebust, Trond
2013-02-25 21:14 ` Andy Lutomirski
2013-02-25 21:49 ` Ric Wheeler
2013-02-25 21:59 ` Myklebust, Trond
2013-02-25 22:16 ` Andy Lutomirski
2013-02-25 23:28 ` Myklebust, Trond
2013-02-25 23:35 ` Andy Lutomirski
2013-02-25 23:45 ` Myklebust, Trond
2013-02-26 0:03 ` Zach Brown
2013-03-11 9:31 ` Joel Becker
2013-02-26 21:02 ` Jörn Engel
2013-02-26 22:35 ` Andy Lutomirski
2013-03-30 19:49 ` Pavel Machek
2013-03-30 20:08 ` Andreas Dilger
2013-03-30 21:45 ` Pavel Machek
2013-03-30 21:57 ` Myklebust, Trond
2013-03-30 23:21 ` Ric Wheeler
2013-03-31 2:53 ` Andreas Dilger
2013-03-31 3:52 ` Myklebust, Trond
2013-03-31 4:18 ` Andy Lutomirski
2013-03-31 4:36 ` Myklebust, Trond
2013-03-31 4:45 ` Myklebust, Trond
2013-04-01 15:49 ` J. Bruce Fields
2013-03-31 7:36 ` Pavel Machek [this message]
2013-03-31 18:27 ` Myklebust, Trond
2013-03-31 18:32 ` openat(..., AT_UNLINKED) was " Pavel Machek
2013-03-31 18:44 ` Myklebust, Trond
2013-03-31 22:50 ` Pavel Machek
2013-03-31 23:14 ` Ric Wheeler
2013-03-31 23:18 ` Pavel Machek
2013-03-31 23:28 ` Ric Wheeler
2013-03-31 23:41 ` Pavel Machek
2013-03-31 5:38 ` AEDilger Gmail
2013-03-31 8:25 ` Pavel Machek
2013-03-31 11:48 ` Pádraig Brady
2013-03-30 22:40 ` Andy Lutomirski
2013-02-21 22:05 ` Ric Wheeler
2013-02-21 22:13 ` Myklebust, Trond
2013-02-22 8:47 ` Ric Wheeler
2013-02-21 18:29 ` Jeremy Allison
2013-02-22 0:29 ` Eric Wong
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=20130331073604.GA13159@amd.pavel.ucw.cz \
--to=pavel@ucw.cz \
--cc=Trond.Myklebust@netapp.com \
--cc=adilger@dilger.ca \
--cc=aviro@redhat.com \
--cc=clmason@fusionio.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=jlbec@evilplan.org \
--cc=joern@logfs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mkp@mkp.net \
--cc=pbonzini@redhat.com \
--cc=rwheeler@redhat.com \
--cc=zab@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).