> Solving this is not trivial, I don't think changing the panic() to
> return(appropriate_error_code) is the rigth thing to do, in some case
> you want to panic if a filesystem gets corrupted.
Indeed, from an overall system robustness perspective, a panic,
reboot, and salvage is, in general, pref
Just FYI, in NetBSD-current, there are on the order of 60 calls to
panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There
appear to be similar numbers in ext2fs and lfs.
No doubt some of them are internal consistancy checks which can't be
triggered by on-disk corruption, but still,
> Solving this is not trivial, I don't think changing the panic() to
> return(appropriate_error_code) is the rigth thing to do, in some case
> you want to panic if a filesystem gets corrupted.
Indeed, from an overall system robustness perspective, a panic,
reboot, and salvage is, in general, pre
Just FYI, in NetBSD-current, there are on the order of 60 calls to
panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There
appear to be similar numbers in ext2fs and lfs.
No doubt some of them are internal consistancy checks which can't be
triggered by on-disk corruption, but still
> Yeah. That's definitely where I'd start from. I think the main obstacle
> for any *BSD system in the ease-of-use department will be the
> must-mount-as-root issue.
huh? NetBSD (at least) allows non-root mounts (forced to
nodev,nosuid, ..) if the user owns the mount point and has appropriate
> Yeah. That's definitely where I'd start from. I think the main obstacle
> for any *BSD system in the ease-of-use department will be the
> must-mount-as-root issue.
huh? NetBSD (at least) allows non-root mounts (forced to
nodev,nosuid, ..) if the user owns the mount point and has appropriat
> Right. Except that UFS has not only generic attibutes. For example,
> you have UF_NODUMP and SF_ARCHIVED. The *only* place in the /sys you
> mention the former is sys/stat.h
Well, right, because backup/restore aren't part of the kernel...
> (BTW, you don't even map it on EXT2_NODUMP_FL).
> Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More
> or less in the same direction, not exactly the same - 4.4 chflags() works
> fine for UFS and leaves other filesystems to map what they can into the
> UFS set.
> Which is bogus - immutable is not a UFS attribute, it's VF
> .. but there remained one that garbled meta-data had made into a
> non-existing block device, that would resist rm -f. He realized
> that the device had an immutable attribute. However, the problem is
> that to change the attribute, you have to open the file before you
> can ioctl() on it;
BSD
9 matches
Mail list logo
