Date: Wed, 10 Mar 2004 23:38:28 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Colin Percival <colin.percival@wadham.ox.ac.uk> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mdioctl.h src/sys/dev/md md.c src/sbin/mdconfig mdconfig.8 mdconfig.c Message-ID: <20040311073828.GU56622@elvis.mu.org> In-Reply-To: <6.0.1.1.1.20040311062306.03f9ade0@imap.sfu.ca> References: <20040311044722.GA93643@regency.nsu.ru> <48203.1078985587@critter.freebsd.dk> <6.0.1.1.1.20040311062306.03f9ade0@imap.sfu.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
* Colin Percival <colin.percival@wadham.ox.ac.uk> [040310 22:31] wrote: > At 06:13 11/03/2004, Poul-Henning Kamp wrote: > >That is a matter of taste more than anything else. A vnode backed md(4) > >device is technically a layering violation, so either the syncer or > >the md(4) code itself (or both) needs to be aware of the special case. > > <kernelnewbie> > Is it really necessary for vnode-backed memory disks to be > accessed through the filesystem? Why can't md(4) hijack the > disk blocks which constitute the file (telling the filesystem > not to touch them, of course) and translate I/O operations > directly into I/O on the underlying device? > </kernelnewbie> That would be harder and make it only work on filesystems that support VOP_BMAP, unless it fell back to VOP_WRITE when BMAP returned ENOTSUP. (VOP_BMAP returns the disk locations for a range of a vnode) Give it a try. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040311073828.GU56622>