[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130331073604.GA13159@amd.pavel.ucw.cz>
Date: Sun, 31 Mar 2013 09:36:07 +0200
From: Pavel Machek <pavel@....cz>
To: "Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc: Andreas Dilger <adilger@...ger.ca>,
Jörn Engel <joern@...fs.org>,
Andy Lutomirski <luto@...capital.net>,
Zach Brown <zab@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Ric Wheeler <rwheeler@...hat.com>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Chris L. Mason" <clmason@...ionio.com>,
Christoph Hellwig <hch@...radead.org>,
Alexander Viro <aviro@...hat.com>,
"Martin K. Petersen" <mkp@....net>, Hannes Reinecke <hare@...e.de>,
Joel Becker <jlbec@...lplan.org>
Subject: Re: New copyfile system call - discuss before LSF?
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists