On Sunday 28 August 2005 11:37 pm, you wrote:
I don't really understand what you're so worked up about: if you don't
like the defaults, don't use them.
Come on now, Dave. I know that you don't really mean this. You are not a
zombie, are you? After all, 'like' is an analog, subjective term.
On Sunday 28 August 2005 11:57 pm, you wrote:
For anything over a 9gb disk, I just make one big / partition. If you
sub partition, you'll always end up filling one (either /var or /tmp
quickly or /usr eventually) and wish you had picked different sizes.
This is a very straight-forward way
C. Michailidis wrote:
Remember, I'm talking about the 'path of least resistance', I understand that
I could label the slice manually with any number of different configurations.
The issue I was hoping to shed some light on is... Can the auto-configuration
mechanism stand to be improved?. Is it
yes, that's quite generous.
why isn't /tmp just an mfs mount though?
On Sun, 28 Aug 2005, Colin Percival wrote:
C. Michailidis wrote:
Remember, I'm talking about the 'path of least resistance', I understand
that
I could label the slice manually with any number of different
On 平成 17/08/29, at 12:30, C. Michailidis wrote:
[...]
I understand that the automatically generated values by sysinstall
are the dumbest settings you can ask for... but auto-allocating a
maximum of 256mb for the root, var, and tmp filesystems (even if
you have an incredibly large slice
Jon Dama wrote:
yes, that's quite generous.
why isn't /tmp just an mfs mount though?
While I like that suggestion personally, some people get perturbed about files
in /tmp going away if the power fails or you reboot.
--
-Chuck
___
C. Michailidis wrote:
This is a very straight-forward way of doing things. Do you really think that
sysinstall should use a similar method when it attempts to auto-configure a
slice?
From what I understand there are quite valid reasons why you would want a
seperate /, /var, /tmp, and /usr.
Rene Ladan wrote:
On Sun, Aug 28, 2005 at 04:30:19PM +0400, Boris Samorodov wrote:
Hi!
As for 5.x notes about -O2 (libalias, gcc) were removed at revision
1.229.2.7 of /usr/src/share/examples/etc/make.conf. But for 6.0-BETA3
we do have these warnings. Should they be removed as for 5.x? Is it
Um, that they may be but... I was under the impression (mistaken?) that
/tmp is a directory defined under the POSIX standard and is in fact
supposed to be flushed in those cases, and that /var/tmp is to be used
for programs desiring persistant storage across shutdowns (scheduled and
unscheduled).
On Monday 29 August 2005 02:23 am, Colin Percival wrote:
The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus
space for one crashdump on /var. If anything, these are vast overkill for
most
systems; on /, for example, it is hard to imagine a situation where a normal
From: C. Michailidis
[sysinstall FS sizing defaults]
... Isn't it safe to make some of the default sizes a
wee bit larger? That is, a 256mb /tmp and /var doesn't seem
appropriate if you have one of these massive modern disk
drives. For christ's sake, I'd gladly give up a GB or two of
On Monday 29 August 2005 02:51 am, you wrote:
The handbook
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disk-organization.html)
has quite a sensible discussion about this:
I knew that there was a reason I liked using sysinstall's automatic filesystem
generation feature :-)
Mark Kirkwood wrote:
FreeBSD's filesystems are very robust should you lose power.
This sentence is completely bogus (or at best: wishful thinking)
and should be deleted.
mkb.
___
freebsd-stable@freebsd.org mailing list
On Monday 29 August 2005 04:24 am, you wrote:
Probably, but a template for something like this isn't simple unless
it's created as part of a general profile-based installer that would
inform sysinstall of the machine's purpose in life. For example, a
Sure, I can understand this perfectly.
C. Michailidis wrote:
Effectively, we are taking a known variable that may fluctuate
greatly (disk size) and completely ignoring it during installation.
Pretty dumb, no? Obviously, this leaves a bad taste in my mouth.
Take it to an extreme and maybe I can convert you to my team.
Imagine
Matthias Buelow wrote:
Mark Kirkwood wrote:
FreeBSD's filesystems are very robust should you lose power.
This sentence is completely bogus (or at best: wishful thinking)
and should be deleted.
It's probably correct if you have hw.ata.wc=0 (and are using IDE drives
obviously).
Mark Kirkwood wrote:
FreeBSD's filesystems are very robust should you lose power.
This sentence is completely bogus (or at best: wishful thinking)
and should be deleted.
It's probably correct if you have hw.ata.wc=0 (and are using IDE drives
obviously).
I'd like to stress the probably. I've
Hey, newb BSDer here with a question
I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root,
I type:
mount /dev/acd0 /cdrom
and I get incorrect super block error message after a bit of CD activity,
and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I
You're trying to mount it as a rw disc and as a UFS file system
mount -r -t cd9660 /dev/acd0 /cdrom
Mark Space wrote:
Hey, newb BSDer here with a question
I've got a brand new 5.4 install. I'm trying to mount the CDROM. As
root, I type:
mount /dev/acd0 /cdrom
and I get incorrect super
Hey, newb BSDer here with a question
I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root,
I type:
mount /dev/acd0 /cdrom
and I get incorrect super block error message after a bit of CD activity,
and no mount. I've tried a CD-RW I burned (the FreeBSD install
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 29, 2005 at 10:16:54PM +1000, [EMAIL PROTECTED] wrote:
Hey, newb BSDer here with a question
I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root,
I type:
mount /dev/acd0 /cdrom
and I get incorrect
You're trying to mount it as a rw disc and as a UFS file system
mount -r -t cd9660 /dev/acd0 /cdrom
Mark Space wrote:
Hey, newb BSDer here with a question
I've got a brand new 5.4 install. I'm trying to mount the CDROM. As
root, I type:
mount /dev/acd0 /cdrom
Of course,
On 29 Aug, Matthias Buelow wrote:
Mark Kirkwood wrote:
FreeBSD's filesystems are very robust should you lose power.
This sentence is completely bogus (or at best: wishful thinking)
and should be deleted.
It's probably correct if you have hw.ata.wc=0 (and are using IDE drives
obviously).
I'd
Don Lewis wrote:
I'd like to stress the probably. I've already seen unrepairable
filesystem corruption with softupdates enabled in the past with
good scsi disks at power loss.
Did you remember to disable write caching by setting the WCE mode page
bit to zero? At least with SCSI, it doesn't
Matthias Buelow wrote:
Don Lewis wrote:
[ ... ]
Did you remember to disable write caching by setting the WCE mode page
bit to zero? At least with SCSI, it doesn't seem to affect performance
under most workloads.
No.. I thought that with SCSI it is ok to leave the cache enabled
because SCSI
Since I upgraded my laptop from 5.3 to 6.0-BETA3 it's doing a lot
of hangs on NFS in both directions. Anyone else noticing this ?
The laptop is OK when running a 5.3 partition. I'm running AMD on
all hosts.
I'm about to run mergemaster -sicv to upgrade my /etc from 5.3 to 6.0-BETA3,
meanwhile
On 29 Aug, Matthias Buelow wrote:
Don Lewis wrote:
I'd like to stress the probably. I've already seen unrepairable
filesystem corruption with softupdates enabled in the past with
good scsi disks at power loss.
Did you remember to disable write caching by setting the WCE mode page
bit to
[ Sorry - I could have sworn I sent this earlier... ]
Announcement
The FreeBSD Release Engineering Team is pleased to announce the availability
of FreeBSD 6.0-BETA3.
This BETA includes a full set of packages for amd64 and i386 architectures.
Alpha has no packages, sparc64 has
Chuck Swiger wrote:
PS: Haven't we had this conversation before?
Yes, indeed, and I don't want to reopen that issue since that would
lead to no new insights (and since I don't have the time atm. to
contribute anything I couldn't provide any stuff myself). I was
just refuting the claim of very
Matthias Buelow wrote:
Chuck Swiger wrote:
PS: Haven't we had this conversation before?
Yes, indeed, and I don't want to reopen that issue since that would
lead to no new insights (and since I don't have the time atm. to
contribute anything I couldn't provide any stuff myself).
Yet you seem
Chuck Swiger wrote:
Matthias Buelow wrote:
Chuck Swiger wrote:
PS: Haven't we had this conversation before?
Yes, indeed, and I don't want to reopen that issue since that would
lead to no new insights (and since I don't have the time atm. to
contribute anything I couldn't provide any
J. T. Farmer wrote:
Chuck Swiger wrote:
Matthias Buelow wrote:
Yes, indeed, and I don't want to reopen that issue since that would
lead to no new insights (and since I don't have the time atm. to
contribute anything I couldn't provide any stuff myself).
Yet you seem willing to spend time
Chuck Swiger wrote:
Yet you seem willing to spend time discussing the matter...?
Because it's somewhat of my pet peeve and I always see the mantra-like
repetition of the argument that you have to disable the write-back
cache if you want any safety at all, which is a) extremely
disadvantageous
Matthias Buelow wrote:
Chuck Swiger wrote:
Yet you seem willing to spend time discussing the matter...?
Because it's somewhat of my pet peeve and I always see the mantra-like
repetition of the argument that you have to disable the write-back
cache if you want any safety at all,
No, there
In the last episode (Aug 26), Jason said:
We are planning on updating a number of old machines, being used as
IDS sensors, and in the past, there has been a known issue regarding
gig speeds and pcap with regards to snort.
Do you have an URL referring to the issue? As long as your pcap
buffers
Chuck Swiger wrote:
I reiterate my question: have you tried adjusting the syncer sysctl's and
seeing whether FreeBSD is more stable in the event of a power failure?
No, simply because I have no machine at the moment for experimenting
if it takes longer until it eats its filesystem. Besides, as
Matthias Buelow wrote:
(snippage...) I was
merely pointing out the inadequacy of talking about robust
filesystems in the context of softupdates and end-consumer harddrives.
Would you be happy if the handbook section added a caution, or referred
to the section that discusses the write cache?
On Tue, 30 Aug 2005, Mark Kirkwood wrote:
(FWIW - I have seen Linux + ext3 systems destroyed by power failure
because the admins refused to disable write caching on ATA drives -
Neither journelling or softupdates is much help if the HW is kidding you
about write acknowledgment).
This would
Kernel and world seem to be ok with -O2, for ports it is not advised.
Hi,
I may have missed a thread or something (just let me know :) ) - why is
-O2 not advised for ports on 6.0?
cheers,
Beto
Simply because not every port works with -O2 optimisations. It caused
bad code in some
Mark Kirkwood wrote:
Would you be happy if the handbook section added a caution, or referred
to the section that discusses the write cache?
Yes, that would inform the user.
(FWIW - I have seen Linux + ext3 systems destroyed by power failure
because the admins refused to disable write caching
Jon Dama wrote:
Ironically, phk backed out the underlying support for this safety fix
from the FreeBSD kernel b.c. it wasn't integrated into the softupdates
code
whereas in reality the proper course of action would have been to hook it
in. :-/
Can it be put into softupdates at all? From what I
On Tue, 2005-08-30 at 03:11 +0200, Matthias Buelow wrote:
BTW., when have you last seen a broken NTFS? While
I don't do Windows much, I have had quite a few crashes on Windows
(2000, XP) over the years on various machines, and I always asked
myself how it could be that the system is up almost
Matthias Buelow wrote:
From what I understand from googling around on that issue, the
write-barrier stuff should make that much more unlikely. Of course
there could be the situation that it was a kernel that did not
(properly) support write-barriers yet, or the Linux implementation
has/had
Well, I think one issue is that it destroys one of the fundamental
advantages of softupdates which was that you could interleave streams of
strongly ordered metadata writes without demanding a sequence for the
streams collectively. By using request barriers, you are effectively
forcing an
On 30 Aug, Matthias Buelow wrote:
Jon Dama wrote:
Ironically, phk backed out the underlying support for this safety fix
from the FreeBSD kernel b.c. it wasn't integrated into the softupdates
code
whereas in reality the proper course of action would have been to hook it
in. :-/
Can it be
On 29 Aug, Jon Dama wrote:
It seems you need to add a layer of indirection. (owing to biodone being
called merely when the drive has cached the request). What you know is
that those operations marked completed by biodone are in fact done only
after a (costly) flush cache operation is
Tijl Coosemans wrote:
A couple days ago I updated my system and was excited to see cpufreq
and powerd in 5-stable. Since then however I noticed that my laptop
temperature is about 5°C higher than with est and estctrl. I found that
cpufreq when setting 200MHz for example set the absolute
47 matches
Mail list logo
