make install trick

I have soft updates enabled on a fast machine at work. make installworld can fill up slash even though it has 15M free before the install. I think this is a bug in softupdates that it doesn't reclaim space quickly enough or in overflow situations. To work around it, I've used make INST

Re: make install trick

According to Warner Losh: > install. I think this is a bug in softupdates that it doesn't reclaim > space quickly enough or in overflow situations. Yes, it is a known issue Kirk know of AFAIK. It should probably reclaim the soon-to-be-freed blocks when it needs them. I've removed softupdates on

RE: make install trick

> I have soft updates enabled on a fast machine at work. make > installworld can fill up slash even though it has 15M free before the > install. I think this is a bug in softupdates that it doesn't reclaim > space quickly enough or in overflow situations. It's really not a bug, it's ju

Re: make install trick

In message <000101bf0f78$fbe58b40$[EMAIL PROTECTED]> "David Schwartz" writes: : It's really not a bug, it's just a missing feature. There's no requirement : that a filesystem reclaim empty space immediately. You really shouldn't be : using fastupdates on nearly full filesystems -- it doesn't

Re: make install trick

On 1999-Oct-06 07:42:39 +1000, Warner Losh wrote: >Nearly full? It is a 32M file system with 15M free. That's not >nearly full. The problem is that the update rate is faster than the >softupdate code can deal with. Running sync between each install >shows that this is a bug. As Ollivier Rober

Re: make install trick

In message <01bf0f86$d8d84670$[EMAIL PROTECTED]> "David Schwartz" writes: : I think anybody reasonable familiar with softupdates understands what : 'sync' does in this context. It's not a bug because it is documented : behavior done for a specific reason. It is a bug. You've just said

RE: make install trick

> In message <000101bf0f78$fbe58b40$[EMAIL PROTECTED]> "David > Schwartz" writes: > : It's really not a bug, it's just a missing feature. There's > no requirement > : that a filesystem reclaim empty space immediately. You really > shouldn't be > : using fastupdates on nearly full filesystems -

Re: make install trick

> In any case, you should not be doing lots of writes to root, so the > lack of softupdates should not be a problem. So, are you suggesting make /tmp it's own disk, otherwise anytime you do development alot of writes are done to /. And, if you do lots of development, then you'll have the same pr

RE: make install trick

On Tue, 5 Oct 1999, David Schwartz wrote: > > > I have soft updates enabled on a fast machine at work. make > > installworld can fill up slash even though it has 15M free before the > > install. I think this is a bug in softupdates that it doesn't reclaim > > space quickly enough or in overfl

Re: make install trick

On 1999-Oct-06 09:02:12 +1000, Nate Williams wrote: >> In any case, you should not be doing lots of writes to root, so the >> lack of softupdates should not be a problem. > >So, are you suggesting make /tmp it's own disk, otherwise anytime you do >development alot of writes are done to /. I've pr

Re: make install trick

On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: >I've seen softupdates nearly eliminate disk io for systems that used >an abmornal amount of temp files, but the fact that it can destabilize >a system worries me greatly. What do you mean by `destabilize'? There are bugs in softupdates whic

Re: make install trick

On Wed, 6 Oct 1999, Peter Jeremy wrote: > On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: > >I've seen softupdates nearly eliminate disk io for systems that used > >an abmornal amount of temp files, but the fact that it can destabilize > >a system worries me greatly. > > What do you mean

Re: make install trick

Nate Williams <[EMAIL PROTECTED]> writes: > > In any case, you should not be doing lots of writes to root, so the > > lack of softupdates should not be a problem. > > So, are you suggesting make /tmp it's own disk, otherwise anytime you do > development alot of writes are done to /. > > And, if

Re: make install trick

On 1999-Oct-06 11:33:51 +1000, Alfred Perlstein wrote: > >On Wed, 6 Oct 1999, Peter Jeremy wrote: > >> On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: >> >I've seen softupdates nearly eliminate disk io for systems that used >> >an abmornal amount of temp files, but the fact that it can dest

Re: make install trick

[.] > Please read more of the thread before replying, the fact of [.] Now if everyone used mailers that actually wrote correct in-reply-to lines, this might be a realistic thing to suggest ! -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>

Re: make install trick

> > In any case, you should not be doing lots of writes to root, so the > > lack of softupdates should not be a problem. > > So, are you suggesting make /tmp it's own disk, otherwise anytime you do > development alot of writes are done to /. > > And, if you do lots of development, then you'll ha

Re: make install trick

> On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: > >I've seen softupdates nearly eliminate disk io for systems that used > >an abmornal amount of temp files, but the fact that it can destabilize > >a system worries me greatly. > > What do you mean by `destabilize'? There are bugs in soft

Re: make install trick

At 6:33 PM -0700 1999/10/5, Alfred Perlstein wrote: > Which isn't an option unless you dedicate a partition for /tmp > which is pretty wasteful imo. Forgive me if I'm misunderstanding something here, but isn't having /tmp on the root filesystem just inviting a denial-of-service attack

Re: make install trick

At 10:51 AM -0400 on 1999/10/6, Garrett Wollman <[EMAIL PROTECTED]> wrote: > Only if you let random lusers log in to your machine. That's not the way I interpret some of the previous comments on this thread. It seems to me that not having /tmp on a separate filesystem has, i

Re: make install trick

< said: > Forgive me if I'm misunderstanding something here, but isn't > having /tmp on the root filesystem just inviting a denial-of-service > attack on yourself? Only if you let random lusers log in to your machine. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O

Re: make install trick

According to Nate Williams: > So, are you suggesting make /tmp it's own disk, otherwise anytime you do > development alot of writes are done to /. Of course /tmp should NOT be on /. Either in its separate FS or on another partition through a symlink. / should be as small and as write-free as pos

Re: make install trick

At 12:22 PM +0200 1999/10/6, Brad Knowles wrote: > Is there something fundamental I'm missing here? I thought > that this sort of thing was taught in SysAdmin 101 My sincerest (and public) apologies to Alfred. There is something pretty fundamental that I was missing -

Re: make install trick

On Wed, Oct 06, 1999 at 02:57:23PM +1000, a little birdie told me that Peter Jeremy remarked > > I guess we disagree on this. My feeling is that write activity on > root should be minimised to minimise the risk that root will be > inconsistent following a crash. Indeed. Thus: /dev/da0s1a on / (

Re: make install trick

> > On Wed, Oct 06, 1999 at 02:57:23PM +1000, a little birdie told me > that Peter Jeremy remarked > > > > I guess we disagree on this. My feeling is that write activity on > > root should be minimised to minimise the risk that root will be > > inconsistent following a crash. > > Indeed. > Thu

Re: make install trick

On Wed, Oct 06, 1999 at 04:18:15PM -0500, a little birdie told me that Kevin Day remarked > > > > /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > > My understanding was that that was just a indication of writes that were > able to be done asynchronously without any risk, so t

Re: make install trick

:Indeed. :Thus: :/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) : ^^^ : :Though I'm still waiting for an explanation of WHY exactly I have async :writes on a sync partition. Nobody yet has said anything but 'that's :interesting...'. A directio

Re: make install trick

On 1999-Oct-06 16:14:19 +1000, Brian Somers wrote: >> On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: >> >I've seen softupdates nearly eliminate disk io for systems that used >> >an abmornal amount of temp files, but the fact that it can destabilize >> >a system worries me greatly. >> >> W

Re: make install trick

On 1999-Oct-07 06:44:19 +1000, Matthew D. Fuller wrote: >/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > >Though I'm still waiting for an explanation of WHY exactly I have async >writes on a sync partition. Nobody yet has said anything b

Re: make install trick

On Wed, 6 Oct 1999, Matthew D. Fuller wrote: > Indeed. > Thus: > /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > > Though I'm still waiting for an explanation of WHY exactly I have async > writes on a sync partition. Nobody yet has sa

Re: make install trick

> /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > > Though I'm still waiting for an explanation of WHY exactly I have async > writes on a sync partition. Nobody yet has said anything but 'that's > interesting...'. A direction to look

Re: make install trick

> It was my understanding that it was standard recommended practice > practice pretty much across the board to create the following > separate filesystems: > > / > /tmp (perhaps an mfs, perhaps softupdates, or whatever) > /usr > /var

Re: make install trick

At 3:21 PM -0700 1999/10/7, David O'Brien wrote: > HP and SGI workstations have a single huge /. Why do you > need /usr seperate from / when you aren't diskless (or /usr'less)? If you've done your job right, it can be mounted read-only. This makes it harder for someone t

Re: make install trick

>If you've done your job right, it can be mounted read-only. This > makes it harder for someone to break into the machine and obtain root > access, because now they have to be root to unmount /usr and remount > it read-write, so that they can put their trojan script on there that > they'r

Re: pfft Re: make install trick

On 1999-Oct-07 01:51:52 +1000, Alfred Perlstein wrote: >First post: > hey, anyone having crashes when doing installworld might like > my INSTALL="sync && install -C" trick I haven't kept that post. My recollection is that the problem was installworld dying, not the system crashing. If I misre

{a}sync updates (was Re: make install trick)

Thank you, this is *EXACTLY* what I was looking for :) On Thu, Oct 07, 1999 at 08:59:00AM +1000, a little birdie told me that Peter Jeremy remarked > > As far as I can tell, the net effect is that inode access time updates > will remain async writes into the filesystem. > > An easy way to tel

Re: {a}sync updates (was Re: make install trick)

:mount(8): : syncAll I/O to the file system should be done synchronously. : :On the gripping hand, you can say, 'this is an ATIME update, there's no :way its presence or lack thereof can do anything bad to the filesystem, :so let it be async since it takes extra work to make it syn

Re: {a}sync updates (was Re: make install trick)

On 1999-Oct-07 09:15:42 +1000, Matthew D. Fuller wrote: >Is this good, bad, ugly, or just inconsistent? On the one hand, you can >argue that 'sync should be sync should be sync, I don't bloody care, just >don't do anything async at all', since that's what it's supposed to do: >mount(8): > sy

Re: {a}sync updates (was Re: make install trick)

On Thu, Oct 07, 1999 at 11:57:26AM +1000, a little birdie told me that Peter Jeremy remarked > > How detailed should the man page be? Exactly my query in writing this ;> > If it stated "all file data will > be written synchronously, but inodes where the only update is atime > and free block b

Re: {a}sync updates (was Re: make install trick)

Maybe the best solution is the following: - leave "sync" with its current behaviour - create a sysctl to make it truely synchronous (I was thinking of a new mount option but thats overkill) and have the documentation for that sysctl state the performance hit and recommend that the filesystem be m

Re: {a}sync updates (was Re: make install trick)

> There should be fairly few writes to the root partition, so having An opionion. I use the HP workstation model where my / is 1800M. I have no use for /var and /usr and find them simply stupid in today's world. (except for ISP's where there is cause for a septerate /var). Lets stick to facts.

Re: {a}sync updates (was Re: make install trick)

> >mount(8): > > syncAll I/O to the file system should be done synchronously. > > How detailed should the man page be? If it stated "all file data will > be written synchronously, but inodes where the only update is atime > and free block bitmaps are written asynchronously", would that

RE: {a}sync updates (was Re: make install trick)

> > There should be fairly few writes to the root partition, so having > > An opionion. I use the HP workstation model where my / is 1800M. I have > no use for /var and /usr and find them simply stupid in today's world. > (except for ISP's where there is cause for a septerate /var). > > Lets sti

Re: {a}sync updates (was Re: make install trick)

On 1999-Oct-08 08:13:12 +1000, David O'Brien wrote: >> >mount(8): >> > syncAll I/O to the file system should be done synchronously. >> >> How detailed should the man page be? If it stated "all file data will >> be written synchronously, but inodes where the only update is atime >> and f

Re: {a}sync updates (was Re: make install trick)

On Thu, Oct 07, 1999 at 03:15:03PM -0700, David Schwartz wrote: > > > There should be fairly few writes to the root partition, so having > > An opionion. I use the HP workstation model where my / is 1800M. I have > You are not disagreeing with him, David. You are just talking about >

RE: {a}sync updates (was Re: make install trick)

> On Thu, Oct 07, 1999 at 03:15:03PM -0700, David Schwartz wrote: > > > > There should be fairly few writes to the root partition, so having > > > An opionion. I use the HP workstation model where my / is > 1800M. I have > > > You are not disagreeing with him, David. You are just talking ab

Re: {a}sync updates (was Re: make install trick)

> We're talking about the special case of small root partitions, such that > softupdates inability to make empty space available quickly can make the > difference between a major operation's success or failure. > > This is almost impossible on a 1.8Gb root partition. Again why? Wha

Re: {a}sync updates (was Re: make install trick)

:> We're talking about the special case of small root partitions, such that :> softupdates inability to make empty space available quickly can make the :> difference between a major operation's success or failure. :> :> This is almost impossible on a 1.8Gb root partition. : :Again why

Re: {a}sync updates (was Re: make install trick)

"David Schwartz" wrote: > We're talking about the special case of small root partitions, such that > softupdates inability to make empty space available quickly can make the > difference between a major operation's success or failure. > > This is almost impossible on a 1.8Gb root part

Re: {a}sync updates (was Re: make install trick)

I have noticed similarly odd behaviour from softupdates during heavy IO load, where something is creating lots of little files or directories and not much else is happening. Using `vmstat 1` I can see that softupdates isn't very good at evening out the IO rate over time: there's a roughly sinusoid