Re: mount: /dev/ad0s1e: File name too long
Bruce Evans <[EMAIL PROTECTED]> writes:
>I think I prefer the old behaviour. The names preserved by the kernel
>can't possibly remain valid until unmount in all cases. Examples:
>- pathnames relative to the current directory work. These only remain
> valid if the process that does the mount also does the unmount (and
> doesn't chdir).
>- the pathnames may involve symlinks that go away or change before
> unmount.
>The fix for this is: don't do that. This is also a reaonable fix for
>long pathnames -- don't use them unless you really have to. Long
>names even mess up the most common uses of the preserved names --
>displaying them in df, mount, etc.
And what if you have to use them (or want to)? If df/mount/etc
have bugs, let's fix those (not that I think they're significant).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: well! That root didn't work! Let's try another!
Matthew Jacob <[EMAIL PROTECTED]> writes:
>> > My FreeBSD-alpha PC164 lost it's IDE disk for 4.2 somehow- which I'd
>> > just loaded the 4.2 kernel from- so it decided to run off of da0
>> > instead, which was -current. Truly a startling turn of
>> > events. Shouldn't one stop and ask if the root one asked for isn't
>> > available?
>>
>> There are two schools of thought here. One says "you should try very
>> hard to find a root device", the other says "you should boot only from
>> the exactly correct root device and complain otherwise". I took the
>> first approach because its advocates shouted more loudly than those of
>> the second.
>> Would a louder warning message be enough of a compromised?
>
>Actually, no. I think very strongly that you shouldn't always look that hard
>automatically- you should look hard to find reasonable choices (you could say,
>da2, 7 and 9 have what *appear* to be filesystems I can use)- but you
>shouldn't just launch onto them- vital customer data corruption can result.
As suggested, if the correct root device can't be found, the boot
_should_ offer you a choice of running off others that appear to be
bootable. Also, I certainly can see instances where someone would want to
have it take an alternate partition to run off of - it could be an
alternate boot behavior programmed into the boot block code at label time.
Note: I don't know exactly what we do now; I'm just taking the above
comments as fact.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
Jim Bloom <[EMAIL PROTECTED]> writes:
>I do plenty of build once and run on multiple machines. My biggest
>machine is a PII 40MHZ where I compile the world and kernels for a 486
>laptop and P-60 Router/Firewall. I would not really want to compile the
>world on these slower machines over nfs.
We also have a number of different machines for which we use a
single kernel/userland compile, ranging from old K6's and PII's (and
perhaps a few Pentium MMX's) to recent PIII's. There are large numbers of
these machines, and no way to reasonably make variant kernels for them
all. I'm sure other people running large numbers of servers accumulated
over time have a similar problem (Yahoo?) So I'd add one vote for making
to easy (or at least not hard) to include multiple architecture
optimizations in one kernel/userland release, ala Solaris.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: disklabel.c & disklabel.8 patch
Bruce Evans <[EMAIL PROTECTED]> writes:
>On Fri, 9 Feb 2001, John W. De Boskey wrote:
>>I've been using the disklabel.c patch which allows easier
>> configuration by being able to specify a new disklabel of
>> the form:
>>I'd like to commit these if no one sees any major problems
>> with them.
>
>These are not suitable for commit in their current form. The
>disklabel.c patch has more than the usual density of style bugs.
>It doesn't even use the normal brace style.
Sorry, my normal personal style definitions in Emacs probably
conflict with "standard" BSD style. I'll rework the style (I'm the author
of the patch). Any other problems while I'm at it?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
Martin Cracauer <[EMAIL PROTECTED]> writes:
>would you please have a look at the following sh fix? My brain is a
>bit rusty and maybe I overlook a drawback.
>
>When a child is receiving SIGSTOP, eval continues with the next
>command. While that is correct for the interactive case (Control-Z
>and you get the prompt back), it is wrong for a shellscript, which
>just continues with the next command, never again waiting for the
>stopped child. Noted when childs from cronjobs were stopped, just to
>make more processes (by wosch).
Careful - is this behavior used as a feature during boot when
starting services? I.e. you can ^Z and it will continue with the next
service; effectively backgrounding the service that's waiting. I.e. is
this a feature (perhaps accidental) that people assume and rely on? And
if so, is there another way to get the functionality, and is it important
to people?
Perhaps I'm totally wrong here and misunderstood the issue.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
"David O'Brien" <[EMAIL PROTECTED]> writes:
>On Thu, Jan 11, 2001 at 02:38:55PM -0800, John Baldwin wrote:
>> Erm, sysinstall can be used as a replacement for fdisk and disklabel,
>> both of which are in /sbin. In fact, in 4.2 the only tool you can
>> realistically use to splat a virgin disklabel onto a slice w/o weird
>> hoop jumping that isn't documented _is_ sysinstall. disklabel should
>> have that fixed by 4.3, however.
>
>But disklabel/fdisk can't even accept MB's as a unit. Until they grow
>the functionality of the NetBSD and OpenBSD versions of them, sysinstall
>is really the only tolerable disk label manipulation tool our users have.
>This includes those with a bummed /usr that needs to install a new disk
>to get it back.
A full set of disklabel patches to support MB, GB, KB, %, and *
(everything not spoken for elsewhere) for sizes (and * for offsets to allow
disklabel to calculate them for you), etc are in Warner's hands. (I got
annoyed at it one evening...) Now, if Warner would commit them :-)
(Matt has looked at the patch also.)
They also have improved error checking, etc.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
>It seems Alfred Perlstein wrote:
>> I have a patch here that removes await/asleep from the kernel API.
>>
>> http://people.freebsd.org/~alfred/noasleep.diff
>>
>> Matt Dillon implemented alseep/await quite some time ago and the
>> only thing that's using it is ata. In order to clean up some of
>> the schduler and vm system I'm removing support for it.
>>
>> Peter Wemm and I suspect that ata doesn't need it. Right now I'm
>> running several make -j128 buildworlds and buildkernels with this
>> patch to catch any ata problems.
U...
It seems to me from reading the man page for asleep/await that
they have significant utility, and that the real issue would be one of
code not using them, especially as people work to remove the Giant
lock for SMP.
Or is the discussion in the man page wrong in some way?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
