>
> :Some thoughts:
> :
> : - If you want softupdates, you need to specify the -S flag. Should
> :softupdates be the default?
>
> That's a hard one. Considering that people who have mfs in their fstab
> probably expect as little disk I/O as possible, softupdate sshould
> proba
:Some thoughts:
:
: - If you want softupdates, you need to specify the -S flag. Should
:softupdates be the default?
That's a hard one. Considering that people who have mfs in their fstab
probably expect as little disk I/O as possible, softupdate sshould
probably be enabled by
[ cvs-(all|commiters) --> -hackers ]
> :
> :>
> :> (this whole thing is predicated on someone writing a mount_md wrapper
> :> for MD that mimics the options mount_mfs accepts, for compatibility).
> :
> :I'll do it. Would it be safe to assume that it's acceptable to write
> :a C program
On 1 Feb, Dima Dorfman wrote:
= [cvs-(all|commiters) -> -hackers]
=
= > >> If anybody writes a patch to mdconfig to DTRT based on some
= > >> less bogus /etc/fstab entries, I'll happily review and commit it.
I, personally, liked the mount_mfs interface. Could it get redone to use
md? Although t
>P.S. Is there any reason the -b (baseaddr) option for preload disks
>is currently unimplemented? The patch implements it (it was one line,
>so I thought 'what the heck'); the ioctl works, but I was unable to
>test it.
Yes, the feature is simply too disgusting right now, and it is a
way too co
It doesn't make sense to pollute 'mdconfig' with functions that we already
have an API available to perform. An API called 'mount'.
Why not write a 'mount_md' program to do all the magic based on fstab
options, similar to what mount_mfs used to do for MFS? A 'mount_md'
would giv
[cvs-(all|commiters) -> -hackers]
> >> If anybody writes a patch to mdconfig to DTRT based on some
> >> less bogus /etc/fstab entries, I'll happily review and commit it.
> >
> >Does this sort of functionality really belong in mdconfig?
>
> Not by definition, and I'm not religious about it.
Okay
7 matches
Mail list logo
