IRIX and Software

Hi all,
Need you lights please and help.
I made a new install from a clean disk to make a 6.5.28 system with 256 swap.
So each time my Octane boot and log in as root i have a new core file of 1GB
even if i delete it, at the next reboot a new one comes again.

I don't know if it's the reason why now i have this error in my SYSLOG :

Nov 8 15:04:47 6B:octane Xsession: root: login
Nov 8 15:04:53 1A:octane unix: ALERT: 4Dwm [1119] - out of logical swap space during fork/sproc - see swap(1M)
Nov 8 15:04:53 1A:octane unix: ALERT: fm [1164] - out of logical swap space during fork/sproc - see swap(1M)
Nov 8 15:05:11 1A:octane unix: ALERT: configmon [1048] - out of logical swap space during brk/sbrk - see swap(1M)
Nov 8 15:06:00 1A:octane unix: ALERT: fm [1130] - out of logical swap space during fork/sproc - see swap(1M)

Please how can i fixe that.
Thankssssssss so much in advance

fvador59 wrote: So each time my Octane boot and log in as root i have a new core file of 1GB
even if i delete it, at the next reboot a new one comes again.

Changing the configuration flag for savecore to off will help with the core file reappearing on each boot.
<as root: chkconfig savecore off - see "man savecore" for details>.

Why it dumps core each time is another issue. A search of comp.sys.sgi.* for "out of logical swap space during fork/sproc - see swap(1M)" might offer some insight. Here's a few related threads:
http://groups.google.com/group/comp.sys ... fb1917b257
http://groups.google.com/group/comp.sys ... 29b090a4b9
http://groups.google.com/group/comp.sys ... bd4c88b108

Thank you so much for your help "recondas"
I think i will chkconfig savecore off to switch off it then
read all your links........i guess i have some many hours of reading now
I guess also maybe a software ask for more Ram than i have and swap is not enough
bigger...do you think it's an idea ?

I think i have found my problem but don't know how to change my swap from 256mb to 512mb ?
This is what i have done when i have created my new system disk:

x/repartition/resize: partition to change = (swap)
fx/repartition/resize: partitioning method = (megabytes(2^20))
enter
fx/repartition/resize: size in megabytes (max 8601)= (128)
256
Use the new partition layout? (no)
yes

how to increase it now to 512mb ?
Thanks a lot.

The swap space really needs to be bigger than 256Mb. Heres a little background...

In modern systems swap needs to be big enough to hold the data from all processes that is not easily reobtainable from its original source. So things like code and read-only variables in a program don't need to be stored in the swap file - they can be discarded at any time and reobtained later from the executable file of the related program. But everything else (read/write variables and arrays in programs, writable shared memory, program stacks, program heaps) will need to be stored in the swapfile if it ever gets paged out of memory for some reason. So you have the above items for every program you are running, and also libraries will potentially have a copy of their associated read/write data for every application that links with them. Even if such items never actually get physically swapped out to disk (swapping ideally only happens due to tight memory conditions), many operating systems like to reserve the space in the swap file for them anyway, as it makes handling out of memory situations easier. (I don't know if IRIX does swap file reservation like this as it is a closed source kernel)

Notice all the calls mentioned in the errors are ones that involve allocating/reserving memory in some way - fork clones an existing process, brk extends the heap.

So you should always have a large-ish swap file. Its difficult to say what size is best, but 1-1.5 or even 2 times the size of RAM is a common setting. Contrary to popular belief, this is purely as a heuristic - there is no way to calculate the exact amount of swap you need based on the amount of RAM you have installed. I've witnessed certified Microsoft "experts" try to explain otherwise to people right in front of me, purely based on their misunderstanding of what happens at kernel level.

kramlq wrote: So you should always have a large-ish swap file. Its difficult to say what size is best, but 1-1.5 or even 2 times the size of RAM is a common setting. Contrary to popular belief, this is purely as a heuristic - there is no way to calculate the exact amount of swap you need based on the amount of RAM you have installed.

Agreed. The amount of swap needed has almost nothing to do with how much RAM is installed; it has everything to do with how the system is used.

I've seen 4 GB systems work just fine with only 256 MB of swap, as long as they were used as general purpose workstations, and they weren't being used to manipulate multiple multi-GB images simultaneously. In my last shop, we generally set swap to 512 MB on IRIX 6.5 systems with drives 9 GB or smaller, and 1 GB on systems with drives 18 GB and larger. Never had to think about it, never ran into a problem. Older systems often had 256 or even 128 MB swap.

By the way, Mac OS X dynamically allocates swap space as swap files. I'm typing this on a MacBook Pro with 2 GB physical RAM under Tiger, while running six Firefox tabs, a full instance of XP Pro via Parallels, a couple of terminal windows, and Lotus Notes. Current swap = 137 MB.

Thank you so much guys for your assistances and nice help.
See much better now, how to use and setup swap.
Swap seems close to Ram and software nedeed.It was the reason of my crashes and cores files.
Thanks again

If you're unable to repartition or create a new swap partition on a secondary disk, IRIX does have the ability to use swap files for additional swap space. There are examples for setting them up in the swap man page - here's the relevant section:

josehill wrote: By the way, Mac OS X dynamically allocates swap space as swap files. I'm typing this on a MacBook Pro with 2 GB physical RAM under Tiger, while running six Firefox tabs, a full instance of XP Pro via Parallels, a couple of terminal windows, and Lotus Notes. Current swap = 137 MB.

how did you check? top? Activity Monitor.app?



from top



uptime ~1 day. before last reboot i had uptime 13 days and swap grew over 4gb.

i have macbook, 1gb memory ( ).
right now running:
opera - 4 windows, each window 20-30 tabs (i have loaded them so when i'm offline can go through them)
photoshop (only small files, <50mb )
activity monitor.app
terminal.app - 5 windows
itunes
mail.app
skype
property list editor.app

Hi toxygen,
I used similar methods to what you described. While those are a lot of Opera tabs, my bet for the source of the difference between our systems is Photoshop, which has a lot of memory management tricks that it performs it is launched. It could also be that with 1 GB RAM, your system needs to start paging to swap earlier than a 2 GB system.
-jh

josehill wrote: Hi toxygen,
I used similar methods to what you described. While those are a lot of Opera tabs, my bet for the source of the difference between our systems is Photoshop, which has a lot of memory management tricks that it performs it is launched. It could also be that with 1 GB RAM, your system needs to start paging to swap earlier than a 2 GB system.
-jh

I'll be little off topic, but as far as I know Tiger can only allocate more and more swap files. Thing is, that after few weeks of uptime that swapfiles grow to heaven size. Leopard is supposed to remedy this situation and being able not only to allocate swap, but also to deallocate it. question is, can anyone prove or deny existence of this essential "feature"?

many thanks

nekonoko wrote: If you're unable to repartition or create a new swap partition on a secondary disk, IRIX does have the ability to use swap files for additional swap space. There are examples for setting them up in the swap man page - here's the relevant section:

Code: Select all

The following adds 50Mb of swap space to the system using a file in the
/swap directory:

/usr/sbin/mkfile 50m /swap/swap1

/sbin/swap -a /swap/swap1

To make this swap area permanent (automatically added at boot time) add
the following line to /etc/fstab:

/swap/swap1 swap swap pri=3 0 0

If at all possible, you should always use a dedicated partition. Using a file for swap means the swapping code needs to go through the filesystem switch every time it needs to read or write a page to disk, so it ends up having to go to other parts of the disk to read and update filesystem metadata first (bitmaps, journalling logs, translate file blocks to blocks on disk etc.). With a raw swap partition on disk, the layout is simpler (typically just a bitmap at the start, followed by the pages) and device access is also simpler (fewer layers of translation).

Considering how easy it is to back up and restore or clone a harddrive under IRIX, I think it is worth taking the time to properly extend the existing swap partition. Expecially if you know your system is already actually needing to swap while running (as in the original post).

Also, bear in mind that if you press the NMI (Non-Maskable Interrupt) button on an IRIX machine (or also if the kernel panics?) then the contents of memory will be written out to swap for later recovery by 'savecore', if enabled.

Since this is about as low-level as it gets, this data is written directly to the partition defined as swap in the volume header - so XVM/XLV concats (etc.) aren't honoured.

(... which is kinda annoying if you have 4Gb of swap split over two disks in a 4Gb machine )

It's interesting to note that IRIX conventionally uses partition 1 as swap, but that this lives at the start of the disk, immediately following the Volume Header, and with the boot partition following this. The reason for this somewhat counter-intuitive configuration is that, especially with older discs, the data rate is much higher closer to the spindle. Indeed, on ancient MFM and RLL discs, there was always an equal number of sectors per cylinder - resulting in high data rates near the spindle (where the sectors were most compressed) and a very low data rate on the outside of the disk (with elongated, low-density sectors). One wonders if, on modern disks, there would be an advantage to placing the swap partition in the centre of the disc, so as to minimise the average seek time.

(Although to arrange this correctly, you'd also have to take into account the disc's physical layout - e.g. how many platters are in use and the exponential increase in the amount of data stored in each track as the tracks increase in length, to ensure that you're in the centre of a platter rather than on an edge)

Changing the subject slightly, does anyone know how modern multi-platter disks arrange their data? Are they effectively a JBOD-type setup where the first platter is filled and then data starts being written to the second, or is it more like a striped setup, where head movement is minimised by writing as much data to the current cylinder as possible before moving on?

stuart wrote: Changing the subject slightly, does anyone know how modern multi-platter disks arrange their data? Are they effectively a JBOD-type setup where the first platter is filled and then data starts being written to the second, or is it more like a striped setup, where head movement is minimised by writing as much data to the current cylinder as possible before moving on?

I am mainly familiar with the internals of traditional UNIX style file systems (Sun/BSD/OSF1 UFS, Linux EXTx). The way they do it is to divide the disk up into logical allocation areas called cylinder groups (each consisting of a number of adjacent cylinders, i.e. disk tracks right down through the platters). The idea is that this forms a localised storage area on the disk, as there is a known limit to the amount of disk arm movement needed between reading any two items in that group. Each cylinder group is essentially treated as you might expect the entire disk to be - it stores its own (portion of the) inode table, its own block allocation bitmap, and then it has its own file blocks. Important stuff like partition tables and superblocks may also be replicated in each cylinder group.

The file system is implemented to build upon this locality (whenever possible): e.g. the data blocks of a file will be allocated in the same cylinder group as the files inode, the inode will be allocated in the same cylinder group as the directory that refers to it, subdirectories will be allocated in the same cylinder group as the parent directory.

The idea is that having read one of the above, you will probably soon want to read the thing that it points to. Having them both in the same cylinder group means they are physically nearby on the disk (i.e. at most no more than N tracks of arm movement apart, where N = number of tracks per cylinder group). If you didn't do this, then something as simple as 'ls -l', which involves iterating through a directory, obtaining the inode for each file referenced, could potentially send the disk arm over and back across the entire disk many times. With a volume group, you know the disk arm will have to move (on average) half way across the volume group (... so N/2 tracks) for each item.

There are various heuristics regarding file placement. Some might try to allocate all data blocks of the same file consecutively. Others used to try and space each block of a file N blocks on disk apart in the same track, where N is based on the time taken to read one block and then transfer it to the host. This area is just guestimates, and is also influenced by disk controller capabilities and caching. As disk technology has progressed, there is less emphasis on trying to be clever than there used to be.

EDIT: Forgot to mention, the on disk layout of XFS uses a similar scheme, but I am not familiar with its allocation policies.

Didn't the rise of SCSI and other LBA-based schemes (and on-disk managing controllers) drastically change the interface to the point where the physical disk location of data is no longer manageable by the O/S?