Date: Wed, 24 Jun 1998 21:08:00 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: chuckr@glue.umd.edu, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG Subject: Re: Heads up: block devices to disappear! Message-ID: <199806241308.VAA12346@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 24 Jun 1998 21:27:36 %2B1000." <199806241127.VAA08509@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> >It's really simple, blockdevices are now only used for mounting, the
> >kernel can easily figure this out, so there is no need to have special
> >device nodes for this.
>
> Block devices are also used for buffering. Examples:
> a) Linux fsck.ext2 does partial sector i/o's, so it does not work
> on character disk devices. It works OK on block disk devices
> despite lack of support for some special ioctls.
> b) The simple binary editor that I use reads/writes precisely the
> bytes bytes inspected/changed. This is normally the correct thing
> for a binary editor to do, but it does not work on character disk
> devices.
Both of these should be able to be made to work for character access to
block orientated devices. specfs truncates and rounds the block accesses
for VBLK devices, I don't see why physio couldn't do something similar.
Breaking this would be a loss of functionality.
Incidently, in kern_physio.c:
struct buf *
phygetvpbuf(dev_t dev, int resid)
{
struct bdevsw *bdsw;
int maxio;
bdsw = cdevsw[major(dev)]->d_bdev;
if (bdsw == NULL)
return getpbuf();
maxio = bdsw->d_maxio;
if (resid > maxio)
resid = maxio;
return getpbuf();
}
What is the point of passing in resid and calculating maxio? It's not
used... the calls to phygetvpbuf() could just as easily be calls to
getpbuf() directly..
> c) Caching of (small) slow media, e.g.,:
> sleep 1000 </dev/fd0 # prevent last close
> tar tvvf /dev/fd0 # inspect floppy contents
> tar xvvf /dev/fd0 ... # read floppy contents from buffer cache.
> The last close prevention may be unnecessary under Linux (Linux at
> least used to not invalidate the cache until disk change), and doesn't
> actually work under FreeBSD (a comment in spec_close() says that
> "... on last close ... we must invalidate any in core blocks", but
> spec_close() actually always invalidates the cache). FreeBSD also
> has problems caching the whole 720 blocks that must be cached to
> completely cache a 1440K floppy, since VMIO buffers aren't used for
> the sub-page block size used for block devices.
tar should be able to lseek() in cases like this (like it does on SCO for
example) meaning this should be largely irrelevant.
Small block sizes have been a long-standing problem..
The specfs last close support is a mess. specfs itself is a hack that
exists because of the need to glue vnodes onto the devsw. If devsw
interface was replaced, driver interface could be vnode oriented. Anyway,
changing this isn't part of what's being talked about right at the moment
though.
> Bruce
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806241308.VAA12346>