From: Julian H. Stacey
Steven Hartland wrote:
data. In addition to that I dont have to sit though 1 hour worth of
offline checks when it crashes for what ever reason which I do on
our
FreeBSD boxes.
[Apologies if I missed something, coming in late on thread, but ...]
FreeBSD-4 does
From: Darren Pilgrim [EMAIL PROTECTED]
Date: Tue, 30 Aug 2005 23:07:16 -0700
Sender: [EMAIL PROTECTED]
From: Julian H. Stacey
Steven Hartland wrote:
data. In addition to that I dont have to sit though 1 hour worth of
offline checks when it crashes for what ever reason which I do on
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.
I wish
I must say in the 10 years of using Windows on my desktop
and on servers I've never once had to deal with NTFS loosing
data. In addition to that I dont have to sit though 1 hour worth
of offline checks when it crashes for what ever reason which I
do on our FreeBSD boxes.
From our experiences,
Chuck Swiger [EMAIL PROTECTED] 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.
Then those people
Steven Hartland wrote:
data. In addition to that I dont have to sit though 1 hour worth
of offline checks when it crashes for what ever reason which I
do on our FreeBSD boxes.
[Apologies if I missed something, coming in late on thread, but ...]
FreeBSD-4 does fsck on dirty filesystems before
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.
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
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
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
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
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
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
In the last episode (Aug 28), C. Michailidis said:
Did you ever see a 300 lb. bodybuilder with legs like pencils? It's
pretty funny. Now imagine a 199gb /usr with a 256mb /tmp /var and /,
look similar? This issue became apparent when I attempted to
portupgrade OpenOffice and the process
43 matches
Mail list logo
