On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
jer...@jeremysanders.net wrote:
Olaf van der Spek wrote:
On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman bell...@nsc.liu.se
wrote:
strncpy(args.name, source, BTRFS_PATH_NAME_MAX);
args.name[BTRFS_PATH_NAME_MAX] = '\0';
That's silly. Isn't
On Thu, Feb 10, 2011 at 12:54 PM, Lars Wirzenius l...@liw.fi wrote:
On to, 2011-02-10 at 11:37 +, Jeremy Sanders wrote:
There's strlcpy, but it's not in glibc because of possible truncation
errors!
snprintf is standard, and should be about as safe as it gets with the
glibc functions.
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
jer...@jeremysanders.net wrote:
Of course C++ strings would be much better... :-)
Yeah, why isn't C++ being used?
Olaf
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
On Sat, Feb 5, 2011 at 3:44 AM, Kirk Wolff
k...@wolffelectronicdesign.com wrote:
one subvolume and not on another. Therefore, it seems to me that
default mount options should be able to be configured for each
subvolume. If you follow this idea through, this means that you would
Is
On Wed, Jan 26, 2011 at 8:30 PM, Chris Mason chris.ma...@oracle.com wrote:
My answer hasn't really changed ;) Replacing file data is a common
operation, but it is still surprisingly complex. Again, the truncate is
O(size of the file) and it is actually impossible to do this atomically
in
On Sat, Jan 8, 2011 at 10:43 PM, Thomas Bellman bell...@nsc.liu.se wrote:
So, basically database transactions with an isolation level of
committed read, for file operations. That's something I have
wanted for a long time, especially if I also get a rollback()
operation, but have never heard
On Sun, Jan 9, 2011 at 7:56 PM, Thomas Bellman bell...@nsc.liu.se wrote:
True, that's why this feature request is here.
Note that it's (ATM) only about single file data replace.
That particular problem was solved with the introduction of the
rename(2) system call in 4.2BSD a bit more than a
On Fri, Jan 7, 2011 at 8:29 PM, Thomas Bellman bell...@nsc.liu.se wrote:
What is the visibility of the changes for other processes supposed
to be in the meantime? I.e., if things happen in this order:
Should be atomic too, at close time.
1. Process A does fda = open(foo.txt,
On Fri, Jan 7, 2011 at 2:55 PM, Mike Fleetwood
mike.fleetw...@googlemail.com wrote:
On 6 January 2011 20:01, Olaf van der Spek olafvds...@gmail.com wrote:
Hi,
Does btrfs support atomic file data replaces?
Hi Olaf,
Yes btrfs does support atomic replace, since kernel 2.6.30 circa June 2009
On Fri, Jan 7, 2011 at 3:01 PM, Olaf van der Spek olafvds...@gmail.com wrote:
According to Ted, via-truncate and via-rename are unsafe. Only fsync,
rename is safe.
Disadvantage of rename is resetting file owner (if non-root), having
issues with meta-data and other stuff.
My proposal
On Fri, Jan 7, 2011 at 3:58 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Olaf van der Spek's message of 2011-01-06 15:01:15 -0500:
Hi,
Does btrfs support atomic file data replaces? Basically, the atomic
variant of this:
// old stage
open(O_TRUNC)
write() // 0+ times
close()
On Fri, Jan 7, 2011 at 4:05 PM, Chris Mason chris.ma...@oracle.com wrote:
The problem is the write() // 0+ times. The kernel has no idea what
new result you want the file to contain because the application isn't
telling us.
Isn't it safe for the kernel to wait until the first write or
On Fri, Jan 7, 2011 at 4:13 PM, Chris Mason chris.ma...@oracle.com wrote:
That's not what I asked. ;)
I asked to wait until the first write (or close). That way, you don't
get unintentional empty files.
One step further, you don't have to keep the data in memory, you're
free to write them to
On Fri, Jan 7, 2011 at 5:12 PM, Chris Mason chris.ma...@oracle.com wrote:
I'm not sure why you would run out of memory in that case.
Well, lets make sure I've got a good handle on the proposed interface:
1) fd = open(some_file, O_ATOMIC)
No, O_TRUNC should be used in open. Maybe it works
On Fri, Jan 7, 2011 at 5:32 PM, Massimo Maggi mass...@.it wrote:
Are you suggesting to do:
1)fopen with O_TRUNC, O_ATOMIC: returns fd to a temporary file
2)application writes to that fd, with one or more system calls, in a
short time or in long time, at his will.
3)at fclose (or even at
Hi,
Does btrfs support atomic file data replaces? Basically, the atomic
variant of this:
// old stage
open(O_TRUNC)
write() // 0+ times
close()
// new state
--
Olaf
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
16 matches
Mail list logo
