On Mon, Aug 29, 2005 at 02:44:48AM -0400, Chuck Swiger wrote:
> 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.
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 frequency
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 exe
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. :-/
>
>
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 additio
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 bu
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 almo
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 wh
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 cachi
> > 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 c
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 wo
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
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
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
buffe
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 a
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
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 disc
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 stuff
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:
>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
[ 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 every
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 mo
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
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
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,
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
>>obv
> 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 /cdro
-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
> 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
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 b
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
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"
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).
__
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 inst
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.
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
http://lists.freebsd.org/mailman
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
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 o
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
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).
40 matches
Mail list logo
