On Mon, Jan 25, 2010 at 05:33:20PM -0500, nixlists wrote:
| On Mon, Jan 25, 2010 at 5:09 PM, Bret S. Lambert <bret.lamb...@gmail.com>
| wrote:
| > On Mon, Jan 25, 2010 at 04:35:48PM -0500, nixlists wrote:
| >> On Mon, Jan 25, 2010 at 4:12 PM, Marco Peereboom <sl...@peereboom.us>
| wrote:
| >> > You are positively ignorant. No need to regurgitate this all over
| >> > again. Take your toy mail implementation and enjoy your hair.
| >>
| >> You are still refusing to give a direct answer to a direct question.
| >> How's that not ignorant? I wonder why that might be... All this "well,
| >> we can't really tell what the hardware may do" crap isn't enough.
| >> Perhaps you don't have an answer....
| >
| > Y'know, if you don't get the fact that the answer you're being given
| > is that, ultimately, there really *isn't* an answer, you need some
| > more zen in your diet.
|
| No, I've been given an answer for the RAID controllers (and even that
| was nebulous), now let's hear it for the SATA.
|
| Again. no write-back cache anywhere, no softupdates, no async mounts,
| does the guarantee in the rename(2) apply to this case?
|
| If it does, then say so . If it doesn't, then say so (and change the
| man page, maybe?).
Maybe you need some more reading skills, maybe I do (because I find
your lack of comprehension troublesome to the point that I doubt I
understand what you're saying). What manpage needs changing again ?
rename(2) ?
rename() guarantees that if to already exists, an instance of to will al-
ways exist, even if the system should crash in the middle of the opera-
tion.
I'm guessing this is the part you're concerned about, is that right ?
Can you explain how the (in)fallability of whatever hardware you're
using comes into play ? Let me spell it out for you.
a) The file exists on disk (it's actually written there .. the bits on
disk (yes, even your shitty, cheap ass SATA disk) spell out the file
that was once written.
If you do a rename, and the system crashes, after the crash the
guarrantee is that the file will be there, no matter what. It may be
the original file, it may be the new file - who knows ? Note that
qmail's Maildir approach tries to guarantee a unique filename for
Maildir/new, so the 'to' argument should never exist.
b) The file hasn't hit the disk proper yet, because of any of the
caches that has been mentioned in this (priceless) thread is holding
on to it for now. For all intents and purposes it doesn't exist (as
far as the disk is concerned) and the guarantee from rename(2) still
holds. Remeber that this is still about 'to' which shouldn't exist,
since the filename is unique.
Now, for your mailserver case, note that no such guarantee is made
about the from argument to the system call. The manpage doesn't say
"either an instance of from or an instance of to will always
exist, even if marco comes out and takes a big steamy dump on your
platters in the middle of the opreation."
Please explain what you think should be changed in the rename manpage.
Mail gets lost when machines go down. Boohoo. krw++
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
