Followup to: <20000329170224.D22862@redhat.com>
By author: "Stephen C. Tweedie" <sct@redhat.com>
In newsgroup: linux.dev.kernel
> >
> > Okay, I do have a question. There are a *number* of applications in
> > which it is far better to lose a file than having a file which looks
> > correct but contains bad data. kernel.org is such as application.
> > What would be the proper kind of filesystem to run?
>
> That's an application problem. For kernel.org, you may well have
> multi-megabyte files which are created gradually over quite some
> time as ftp uploads take place: do you expect the filesystem to be
> able to tell the difference between a successful and an unsuccessful
> upload and delete the file if it went wrong?
>
> In this sort of case, you want the application to create a temporary
> file, fsync it, and then rename it to its final destination if you
> want the consistency of the final file to be guaranteed.
>
I still don't see why I can't realistically expect the filesystem to
always give me a consistent view of the file -- either the whole file
or a *proper* (truncated, typically) subset of it.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:26 EST