>>>>> "gm" == Gary Mills <mi...@cc.umanitoba.ca> writes:
gm> That implies that ZFS will have to detect removable devices
gm> and treat them differently than fixed devices.
please, no more of this garbage, no more hidden unchangeable automatic
condescending behavior. The whole format vs rmformat mess is just
ridiculous. And software and hardware developers alike have both
proven themselves incapable of settling on a definition of
``removeable'' that fits with actual use-cases like: FC/iSCSI;
hot-swappable SATA; adapters that have removeable sockets on both ends
like USB-to-SD, firewire CD-ROM's, SATA/SAS port multipliers, and so
on.
As we've said many times, if the devices are working properly, then
they can be unplugged uncleanly without corrupting the pool, and
without corrupting any other non-Microsoft filesystem. This is an
old, SOLVED, problem. It's ridiculous hypocricy to make whole
filesystems DSYNC, to even _invent the possibility for the filesystem
to be DSYNC_, just because it is possible to remove something. Will
you do the same thing because it is possible for your laptop's battery
to run out? just, STOP! If the devices are broken, the problem is
that they're broken, not that they're removeable.
personally, I think everything with a broken write cache should be
black-listed in the kernel and attach read-only by default, whether
it's a USB bridge or a SATA disk. This will not be perfect because
USB bridges, RAID layers and iSCSI targets, will often hide the
identity of the SATA drive behind them, and of course people will
demand a way to disable it. but if you want to be ``safe'', then for
the sake of making the point, THIS is the right way to do it, not muck
around with these overloaded notions of ``removeable''.
Also, the so-far unacknowledged ``iSCSI/FC Write Hole'' should be
fixed so that a copy of all written data is held in the initiator's
buffer cache until it's verified as *on the physical platter/NVRAM* so
that it can be replayed if necessary, and SYNC CACHE commands are
allowed to fail far enough that even *things which USE the initiator,
like ZFS* will understand what it means when SYNC CACHE fails, and
bounced connections are handled correctly---otherwise, when
connections bounce or SYNC CACHE returns failure, correctness requires
that the initiator pretend like its plug was pulled and panic. Short
of that the initiator system must forcibly unmount all filesystems
using that device and kill all processes that had files open on those
filesystems.
And sysadmins should have and know how to cleverly use a
tool that tests for both functioning barriers and working SYNC CACHE,
end-to-end.
NO more ``removeable'' attributes, please! You are just pretending to
solve a much bigger problem, and making things clumsy and disgusting
in the process.
pgpoCtG5UI9HX.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
