From owner-freebsd-hackers@freebsd.org Mon Jan 16 10:56:45 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 18F18CB065C for ; Mon, 16 Jan 2017 10:56:45 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F4B1181D for ; Mon, 16 Jan 2017 10:56:44 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id c85so153390987wmi.1 for ; Mon, 16 Jan 2017 02:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lCp0Rt0cqxquCwhJ62p3HvVzGPib4b7h2MLesXrMl1o=; b=p6IQOghtsAmNv494CtsoF3NamDPbAy/welZbO18D7WSAqIok4pzLUP9djvMoS9CGol MATHKVSwRYI9FYjEEdWfUD1SK5RJ7Pd/jXlqX6MUGYf+yfIR27vEDEBzNqdhv3Il1dQt xfvy3lU8TQrJSmaOmyalX60pyKEm/1ypILOEbPMNUO19GhObut3JqACTj5iX9wjvSOnL 5A4NHrolv3GBmOy5o4qdfpW23m1Nox3XMrNXPuJ15KoHhtISJzizxWYKiKZOwU2pqDdL Cg016CuHcQASExlZKMD/Jywmu07lpcZlCb2Of3EvA+EJAd3YLeP8I4Z7joHTC9r4iA5C zXBg== 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=lCp0Rt0cqxquCwhJ62p3HvVzGPib4b7h2MLesXrMl1o=; b=rnOQ5XT3g4SwJS6bueRJXVz9//utDjWH7Rzzc85ZwsXadm1AtmhcQ4wefsrVSU5U7Q tM56f1O5sw1Y7ZZ4DNUEgozv2GOfvyrOmJNg5BkCdogqL2m7gOH9LNXfnHhTkhdEur+o TKZiq5nMP/8IO+9bW8lIFkB9RiGwnZe5OpjypiTbDwgwkT5TI7ne0hx0NnwHUmiF/Y8b U98cge3qQIEG7f1uOAU+XsNaaQScSPL+DhWSYNrdiPDozwgXKVoTWKYAwYoRwJdwvZAc rmVL/ZHQoXZtzF0OpG1C2QY2P0otupywLV4T+vX4BQCqI4unJCGE9rF4X9UqGh53tpT6 PWZA== X-Gm-Message-State: AIkVDXLKRTkiTxn37lBRaZnSZ8xOYOvLHqD36I3vTtJm01mYcC2ENhNR0T3K6jRi5T25gFdwJtVFnV03x9/x2g== X-Received: by 10.223.163.30 with SMTP id c30mr1114064wrb.40.1484564202868; Mon, 16 Jan 2017 02:56:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.12.46 with HTTP; Mon, 16 Jan 2017 02:56:42 -0800 (PST) In-Reply-To: References: <20170116071105.GB4560@eureka.lemis.com> <29469.1484559072@critter.freebsd.dk> <3a76c14b-d3a1-755b-e894-2869cd42aeb6@rlwinm.de> From: Aijaz Baig Date: Mon, 16 Jan 2017 16:26:42 +0530 Message-ID: Subject: Fwd: Understanding the rationale behind dropping of "block devices" To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Mon, 16 Jan 2017 10:56:45 -0000 Oh thank you everyone for clearing the air a bit. Although for a noob like myself, that was mighty concise! Nevertheless, let me re-iterate what has been summarized in the last two mails so I know I got exactly what was being said. Let me begin that I come from the Linux world where there has traditionally been two separate caches, the "buffer cache" and the "page cache" although almost all IO is now driven through the "page cache". The buffer cache still remains however it now only caches disk blocks ( https://www.quora.com/What-is-the-difference-between- Buffers-and-Cached-columns-in-proc-meminfo-output). So 'read' and 'write' were satisfied through the buffer cache whereas 'fwrite/read', 'mmap' went through the page cache (which was actually populated by reading the buffer cache thereby wasting almost twice the memory and compute cycles). Hence the merging. Nevertheless, as had been mentioned by Julian, it appears that there is no "buffer cache" so to speak (is that correct Julian??) > If you want device M, at offset N we will fetch it for you from the device, DMA'd directly into your address space, but there is no cached copy. Instead it appears FreeBSD has a generic 'VM object' that is used to address myriad entities including disks and as such all operations have to go through the VM subsystem now. Does that also mean that there is no way an application can directly use raw disks? At least it appears so > The added complexity of carrying around two alternate interfaces to the same devices was judged by those who did the work to be not worth the small gain available to the very few people who used raw devices Thank you for all your inputs and waiting to hear more! Al though a bit more context would really help noobs (both to enterprise storage and FreeBSD) like me! I must add that I am getting confused specifically between two different things here: >From the replies above it appears that all disk accesses have to go through the VM subsystem now (so no raw disk accesses) however the arch handbook says raw interfaces are the way to go for disks ( https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html)? Secondly, I presume that the VM subsystem has it's own caching and buffering mechanism that is independent to the file system so an IO can choose to skip buffering at the file-system layer however it will still be served by the VM cache irrespective of whatever the VM object maps to. Is that true? I believe this is what is meant by 'caching' at the VM layer. Keen to hear On Mon, Jan 16, 2017 at 3:56 PM, Jan Bramkamp wrote: > On 16/01/2017 10:31, Poul-Henning Kamp wrote: > >> -------- >> In message , Julian >> Elischer >> writes: >> >> Having said that, it would be trivial to add a 'caching' geom layer to >>> the system but that has never been needed. >>> >> >> A tinker-toy-cache like that would be architecturally disgusting. >> >> The right solution would be to enable mmap(2)'ing of disk(-like) >> devices, leveraging the VM systems exsting code for caching and >> optimistic prefetch/clustering, including the very primitive >> cache-control/visibility offered by madvise(2), mincore(2), mprotect(2), >> msync(2) etc. >> >> Enabling mmap(2) on devices would be nice, but it would also create > problems with revoke(2). The revoke(2) syscall allows revoking access to > open devices (e.g. a serial console). This is required to securely logout > users. The existing file descriptors are marked as revoked an will return > EIO on every access. How would you implement gracefully revoking mapped > device memory? Killing all those processes with SIGBUS/SIGSEGV would keep > the system secure, but it would be far from elegant. > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > -- Best Regards, Aijaz Baig -- Best Regards, Aijaz Baig