Date: Mon, 18 Oct 1999 11:46:35 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Smith <mike@smith.net.au> Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: You gotta be kidding .... Re: cvs commit: src/sys/miscfs/specfs spec_vnops.c Message-ID: <199910181846.LAA69296@apollo.backplane.com> References: <199910181825.LAA01258@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> Instead, the appropriate way is to turn off user level blockdev
:> access entirely. This is the conclusion that was made weeks ago
:> when you first started your rampage to blow away block devices. A
:> time table was also proposed at that time and I committed a sysctl
:> to implement it (which you attempted to remove two weeks ago, which
:> led to blowup #2).
:
:That's what this basically does; it just shortcuts the the old block
:device entries to the character device to avoid violating POLA, so that
:people can experiment with life on a system with nothing that behaves
:like a "block device".
Block devices and character devices have very different operational
characteristics. For example, block devices allow reblocking while
character devices do not. Block devices handle EOF differently then
character devices. Simply folding them together means that anyone
actually using block devices may not notice an immediate problem and
this could result in corruption or unexpected operation without a specific
error being returned.
For example, take fsck on devices with > 512 byte sector sizes. Simply
put, it doesn't work on a character device under all circumstances but
*does* tend to work if the filesystem doesn't have any problems. The same
fsck works through a block device just fine due to the block device's
reblocking capabilities.
It makes no sense whatsoever to fold block devices into character devices
if the goal is to eventually remove the block devices. Doing so does not
encourage users actually using block device access points to move to
character device access points (when such a move is possible), because
the users would not necessarily see any sort of error with their existing
setups.
Diabling block devices entirely is the only proper way to migrate users
to character device entry points and also results in greater visibility
of the change to the user without necessarily screwing the user up.
This is what was discussed many weeks ago when Poul first started his
rampage, at which time I proposed and got support for a sysctl and time
table to disable block devices.
Poul has completely ignored the proposal, time table, sysctl, and the
several major figures that supported it and has gone ahead with his own
plans, refusing to work with or accept the advise of anyone else on the
matter. I believe Poul's action to be entirely improper and, frankly,
if it were up to me I'd pull both his core status and his commit privs
for this third direct infraction.
But my main interest is to avoid causing any major discomfort to customers
who might actually be using block devices, which is why the original
time table proposed a sysctl which would turn off block device access
through a major release prior to block device access being removed from
the source tree entirely, to catch anyone actually using block devices.
Poul's time table not only does not accomplish an easy shift for any
customer using block devices, it is so far compressed that to the customer
the shift might as well be instantanious. As developers, we have a
responsibility to our customers and this commit is an abbrogation of that
responsibility. In spades. It's as simple as that.
I don't know if people have short memories or what, but this whole mess
was discussed four weeks ago and nothing, I repeat NOTHING has changed
since then.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910181846.LAA69296>