From owner-freebsd-hackers@freebsd.org Tue Jan 17 12:05:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DB5DCB4B37 for ; Tue, 17 Jan 2017 12:05:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31E0D1F8C for ; Tue, 17 Jan 2017 12:05:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 99D341FE025; Tue, 17 Jan 2017 13:05:05 +0100 (CET) Subject: Re: Fwd: Understanding the rationale behind dropping of "block devices" To: Aijaz Baig , FreeBSD Hackers References: <20170116071105.GB4560@eureka.lemis.com> <29469.1484559072@critter.freebsd.dk> <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de> From: Hans Petter Selasky Message-ID: Date: Tue, 17 Jan 2017 13:04:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:05:24 -0000 On 01/16/17 11:56, Aijaz Baig wrote: > Nevertheless, as had been mentioned by Julian, it appears that there is no > "buffer cache" so to speak (is that correct Julian??) Hi, When you open the raw disk block device, like /dev/da0 for a USB disk, there is no buffering involved. Every read() and write() request which you make is transformed into a SCSI command and directly passed to the underlying device driver. I know Linux implements a cache for its "/dev/da0" and FreeBSD not. However, if you do "mount -t xxx /dev/da0 /mnt" the filesystem layer might implement a cache for accessing files inside the mounted directory. Some filesystems like ZFS requires more memory for caching data to be efficient than UFS, for example. In FreeBSD you can use a tool called "dd" to measure basic disk performance. Compare it with Linux if you like: Read test (block device): dd if=/dev/da0 of=/dev/null bs=65536 count=10000 Write test (WARNING: This will destroy your disk contents) dd if=/dev/zero of=/dev/da0 bs=65536 count=10000 Write test (filesystem): dd if=/dev/zero of=/mnt/myfile.bin bs=65536 count=10000 Read test (filesystem): dd if=/mnt/myfile.bin of=/dev/null bs=65536 count=10000 You can try running: umount /mnt mount -t XXX /dev/daX /mnt Between the tests and see what happens. Also see the "sync" command. For more serious benchmarking you'll find some utilities in FreeBSD ports, /usr/ports/benchmarks . --HPS