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 fsync ) atomically swap "data pointer" of "real file" with "temp file", then delete temp.In a transparent mode to userland. (something similar to e4defrag). Is this sum up correct?
Massimo Maggi Il 07/01/2011 16:17, Olaf van der Spek ha scritto: > 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 disk. You just wouldn't update the meta-data >>> (yet). >> Sorry ;) Picture an application that truncates 1024 files without closing any >> of them. Basically any operation that includes the kernel waiting for >> applications because they promise to do something soon is a denial of >> service attack, or a really easy way to run out of memory on the box. > I'm not sure why you would run out of memory in that case. > > O_ATOMIC would be the solution for the rename workaround: write temp > file, rename > With advantages like a way simpler API, no issues with resetting > meta-data, no issues with temp file and maybe better performance. > > Olaf > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
