Git development
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "Michael S. Tsirkin" <mst@mellanox.co.il>,
	Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org
Subject: Re: tree corrupted on disk quota full
Date: Thu, 11 Jan 2007 22:10:44 +0000	[thread overview]
Message-ID: <45A6B5E4.3050007@shadowen.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0701111353030.3594@woody.osdl.org>

Linus Torvalds wrote:
> 
> On Thu, 11 Jan 2007, Andy Whitcroft wrote:
>> The call was intended to replace a common idiom:
>>
>> if (xwrite(fd, buf, size) != size)
>> 	error
> 
> I really don't agree.
> 
> You should use "write_or_die()" for this idiom.
> 
> There really is two cases:
>  - the complex and robust one: "we will keep writing even in the presense 
>    of partial writes".
> 
>    This is "xwrite()". 
> 
>  - the simple case: "write everything", anything else is an error. This is 
>    "write_or_die()", or "write_in_full()".
> 
> And I claim, that for the "write_in_full()" case, if you EVER get anything 
> but the full length back, that's an error.
> 
> And it should be treated as such. There is NO POINT in write_in_full() 
> ever returning a partial result. It's unrecoverable by design - and if it 
> wasn't, you wouldn't use "write_in_full()" in the first place, you'd just 
> use "xwrite()".
> 
> And returning a partial result in that case is just a recipe for disaster. 
> I already pointed to one real bug due to this: write_buffer() was (and 
> currently is) simply buggy. And it's buggy EXACTLY becaue 
> "write_in_full()" was doing the wrong thing, and just made it easy to 
> write buggy code - it was no easier to use than xwrite(), and thus there 
> was no point to it. Might as well have just used xwrite() in the first 
> place.
> 
> So I repeat: either you use "xwrite()" (and handle the partial case), or 
> you use "write_in_full()" (and the partial case is an *ERROR*). There is 
> no sane middle ground in between those cases.

Things should be safe in general with the code as it is as we are
checking the write length.  But it is clear that converting to an error
would simplify and clean up the code.  Should have done that the first
time.

If its not done in the morning, I'll fix it up.

-apw

  reply	other threads:[~2007-01-11 22:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-11 12:57 tree corrupted on disk quota full Michael S. Tsirkin
2007-01-11 13:40 ` Andreas Ericsson
2007-01-11 13:43   ` Andy Whitcroft
2007-01-11 13:59   ` Michael S. Tsirkin
2007-01-11 14:28     ` Andreas Ericsson
2007-01-11 18:31 ` Linus Torvalds
2007-01-11 19:19   ` Linus Torvalds
2007-01-11 20:03     ` Linus Torvalds
2007-01-11 21:02     ` Junio C Hamano
2007-01-11 21:17     ` Andy Whitcroft
2007-01-11 21:27       ` Junio C Hamano
2007-01-11 22:09         ` Better error messages for corrupt databases Linus Torvalds
2007-01-12  0:40           ` Shawn O. Pearce
2007-01-11 21:59       ` tree corrupted on disk quota full Linus Torvalds
2007-01-11 22:10         ` Andy Whitcroft [this message]
2007-01-11 22:32           ` Linus Torvalds
2007-01-11 21:11   ` Michael S. Tsirkin
2007-01-11 21:50     ` Linus Torvalds
2007-01-11 21:58       ` Michael S. Tsirkin
2007-01-11 22:24         ` Linus Torvalds
2007-01-11 22:39           ` Michael S. Tsirkin
2007-01-12  0:42             ` Linus Torvalds
2007-01-12  0:51               ` Shawn O. Pearce
2007-01-13  0:53           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45A6B5E4.3050007@shadowen.org \
    --to=apw@shadowen.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=mst@mellanox.co.il \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox