tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
fdiscard error cases
Currently filesystems that don't support discard fail with EOPNOTSUPP,
devices that don't support discard fail with ENODEV, and once you get
to the hardware devices that don't feel like doing TRIM fail silently
(as TRIM is an advisory operation...).
It was pointed out that it would be well to distinguish devices that
don't currently support discard, but theoretically should (because
they're disks) from devices where it makes no sense (e.g. ttys). This
is probably a good idea.
The question is: what errnos to use for which cases? I'd originally
suggested ENOSYS for the ones where it's just not implemented, but
this is traditionally not appropriate (ENOSYS being meant for
unimplemented whole syscalls)... another choice is to use EOPNOTSUPP
for the devices that should theoretically support discard, but it was
also at the same time proposed to use ENODEV for those and EOPNOTSUPP
for devices where it doesn't make sense.
Currently ENODEV prints "Operation not supported by device" and
EOPNOTSUPP prints "Operation not supported". Traditionally EOPNOTSUPP
is for sockets, of course... although that stopped being strictly true
some time ago. (Then there's also ENOTSUP, which posix invented when
they needed EOPNOTSUPP but didn't have it.)
The devices in question are ccd, cgd (maybe), ld, raidframe, and vnd,
and it might make sense to apply the same errno in sd until it gains
support for the SAS equivalent of TRIM... and maybe also in other
random disk devices, like the vax ones. (It's also possible that vax
disks should accept and ignore discard...)
Another option is to add a new errno for "Operation not implemented on
this object" or the like, to be a bit clearer about the distinction
between "not appropriate" and "not implemented" and maintain the
distinction between not implemented at the syscall level and not
implemented on a particular backend entity. But, adding errnos is not
something to do lightly...
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index