From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112939 invoked by alias); 19 Dec 2017 16:36:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 112752 invoked by uid 89); 19 Dec 2017 16:36:00 -0000 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 Received: from mail-qk0-f177.google.com (HELO mail-qk0-f177.google.com) (209.85.220.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 16:35:58 +0000 Received: by mail-qk0-f177.google.com with SMTP id p13so7184280qke.4 for ; Tue, 19 Dec 2017 08:35:58 -0800 (PST) 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 Received: by 10.237.58.41 with HTTP; Tue, 19 Dec 2017 08:35:21 -0800 (PST) In-Reply-To: <9f29d418-10af-1dc7-2636-89cae1eb16f4@redhat.com> References: <20171218131035.GB11285@calimero.vinschen.de> <5a385ced.195b9d0a.d434.5400@mx.google.com> <20171219091431.GF11285@calimero.vinschen.de> <9f29d418-10af-1dc7-2636-89cae1eb16f4@redhat.com> From: Ivan Kozik Date: Tue, 19 Dec 2017 18:18:00 -0000 Message-ID: Subject: Re: Wrong file position after writing 65537 bytes to block device To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00199.txt.bz2 On Tue, Dec 19, 2017 at 4:13 PM, Eric Blake 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