X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=lptzKIw
	ur0o6P3hj2e1tCVZQaNYKzHeE1b0Mikv4sMnkw1fuJvNl0p+aXhQLoxFivEExj+G
	ag6DIdMiXaICBLn2jc2xIXf7Uj6Sf6FYYp18pj5Ay09aocSOfjdrip5tRobTE781
	OwnYtG81VL5jJZ0GFqCtTX+kklBNkFnIig3o=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=lDGrVW4Ev2mce
	6Vh96gv2f0GDN4=; b=p0uZ59K2AQ+dYubYGdKdRuhjCXUTBNX/47Uoi6CxKiq/u
	ZsgSO0bh+yaOFgtCqtwKGhWCZR73RWtDAjiGkK6blggtAGnuLeEfAIQW1diqTKXH
	r4txwwcijIQpJ7fCvwgbYqOSGatjd6F+8xJj4e8bfeLk08HS9MngHVT715NAok=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=watching, accompanying, sdn, piping
X-HELO:	mail-qk0-f177.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3MAYYib3R38nzYfA1b7bZ4KzgixXnn22UDWkeKz4q1E=; b=VwNgxZxXcuN4k279Hf5wLsczLe6saQlAh6OgNfruRhUbkQP67q3MI7Wdq4r7puYT8x qy3kUVtG7POlbHGqG3TlrIfHfxAsXYne2CaIDiraWz3LGV35vjDSiDeVOvmWz3knwx5a kiCnHS85X3/CGqqXbZeetq91uvc0EqxhATTAr63PehhX2Am52x2E7jHsINYYM+oKfGwS MbnlPfFka/fho2g+l7QmA8IKmotXRUHF2qMAZLuy8TF8ssbxoKWsGouam7RRZIA9uGGs 1l8eLSr+21pB5IACOB2/evKWygpu+hR3yScK9lydmTlio0Ojs5niDMGOLoac+DtbpKqk heOw==
X-Gm-Message-State:	AKGB3mKCrm0jy01e776yKUWr49wd9VEG+IxL6qfJZ0YvyPFicS6czLOC 1C40SmBCch7PYfvzpAZktcKxUyQdS47gG6WghCJJ+Eib
X-Google-Smtp-Source:	ACJfBoteZspHhQZrncukVWdRjdcI4mWIkOzR7Jv7zg6bzIitfnVgJgqI42ixZOctbaawiTTsAp9em2syG1iXlj9+WC0=
X-Received:	by 10.55.168.194 with SMTP id r185mr5497725qke.202.1513701354530; Tue, 19 Dec 2017 08:35:54 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<9f29d418-10af-1dc7-2636-89cae1eb16f4@redhat.com>
References:	<20171218131035 DOT GB11285 AT calimero DOT vinschen DOT de> <5a385ced DOT 195b9d0a DOT d434 DOT 5400 AT mx DOT google DOT com> <20171219091431 DOT GF11285 AT calimero DOT vinschen DOT de> <CAKyntiLyTBGcAx3iwhq7dX0wqiE3S685kwmhMg+U2A3huXVzUQ AT mail DOT gmail DOT com> <9f29d418-10af-1dc7-2636-89cae1eb16f4 AT redhat DOT com>
From:	Ivan Kozik <ivan AT ludios DOT org>
Date:	Tue, 19 Dec 2017 16:35:21 +0000
Message-ID:	<CAKyntiLJTjk+5Qs0jAjxAUPJTzfY4R57GRaQjZLwBBeuMM++0Q@mail.gmail.com>
Subject:	Re: Wrong file position after writing 65537 bytes to block device
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On Tue, Dec 19, 2017 at 4:13 PM, Eric Blake <eblake AT redhat DOT com> wrote:
> Can block devices report an unaligned offset to lseek()?  If not, then when
> writing an unaligned value to a block device, don't we have to do a
> read-modify-write of the larger aligned cluster, and then put lseek() back
> to the unaligned boundary, and have extra magic in ftell() to track that we
> are at an unaligned position within the block device?  But that sounds like
> a lot of nasty overhead; and that it would be better to make sure that block
> devices can report unaligned lseek() locations (caveat: I haven't tested
> what Linux does in that regards).

From what I observe on Linux, it supports writing at any offset to the
block device because it does a read-modify-write behind the scenes,
with accompanying nasty overhead (e.g. writes going at 64MB/s instead
of an "expected" 180MB/s).

I think you can observe this behavior on Linux by piping this
program's stdout to a block device (note: must be python3, not
python2):

#!/usr/bin/python3

import sys

block = b" " * 4096
while True:
    sys.stdout.buffer.write(block)
    sys.stdout.buffer.write(b" ")

and watching the block device activity with `dstat -d -D sdN` - you
should see a lot of reads.

Ivan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -