Subject: Re: mosaic problem
To: None <abs@netbsd.org>
From: Daniel Senderowicz <daniel@synchrods.synchrods.COM>
List: port-pmax
Date: 01/18/2000 10:16:40
Essentially what you're saying is that there is a limit of 2^32
in the size of each filesystem that NetBSD can handle, right?
So if I build smaller file systems to handle problems like
this, is there any other limitations that I should be aware of?

Dan

>	It could be down to the amount of data in each filesystem -
>	if one has 5MB and the other 7MB it will probably work on the
>	5MB (5%4 = 1MB) and fail on the other (7%4 = 3MB = -1MB if its
>	treated as signed).
>
>	There could be another explanation - its difficult to tell
>	without looking at the code :)
>
>
>		David/absolute
>
>On Mon, 17 Jan 2000, Daniel Senderowicz wrote:
>
>> Your explanation makes sense, however how is it that the
>> filesystems on both machines are the same in size (/ and /usr),
>> and it works in one and not in the other one?
>> 
>> >	My guess is it is checking for available space before writing
>> >	a file - unfortunately it it probably using a 32bit number,
>> >	rather than off_t so it overflows at 2GB.
>> >
>> >	If you have the time it would be good to track down the error
>> >	message you see in the source, which should be where it makes
>> >	the check, and change the variables it uses to off_t. If you
>> >	do not have thetime to do this, send a pr with send-pr, and
>> >	keep your homedir on a filesystem with less than 2GB free :)
>> >
>> >
>> >		David/absolute
>> >
>> >On Mon, 17 Jan 2000, Daniel Senderowicz wrote:
>> >
>> >> If I run it as root, it seems to work, at least it doesn't print
>> >> those messages. I had other problems, probably related to the
>> >> fact that all the X stuff is not set up for the root login.
>> >> 
>> >> >	What happens if you cd to / and try running it as root?
>> >> >
>> >> >		David/absolute
>> >> >
>> >> >On Mon, 17 Jan 2000, Daniel Senderowicz wrote:
>> >> >
>> >> >> Here are the setups:
>> >> >> 
>> >> >> /etc/fstab:
>> >> >> 
>> >> >> /dev/rz0a / ffs rw 1 1
>> >> >> /dev/rz0b none swap sw 0 0
>> >> >> /dev/rz0d /usr ffs rw 1 2
>> >> >> /kern /kern kernfs rw
>> >> >> 
>> >> >> # df -k
>> >> >> Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>> >> >> /dev/rz0a       31469    24039     5856    80%    /
>> >> >> /dev/rz0d     8282050   517320  7350627     6%    /usr
>> >> >> kernfs              1        1        0   100%    /kern
>> >> >> 
>> >> >> # df -k /var/tmp
>> >> >> Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>> >> >> /dev/rz0a       31469    24040     5855    80%    /
>> >> >> 
>> >> >> >	Is the one with the problem running on a partition with
>> >> >> >	more than 2GB free?
>> >> >> >
>> >> >> >
>> >> >> >		David/absolute
>> >> >> >
>> >> >> >On Mon, 17 Jan 2000, Daniel Senderowicz wrote:
>> >> >> >
>> >> >> >> Hi folks,
>> >> >> >> 
>> >> >> >> I'm struggling with a problem with mosaic. Here it goes:
>> >> >> >> 
>> >> >> >> I have 1.4.1 (with the 1.4.2_ALPHA kernel) and 1.4.2_ALPHA in
>> >> >> >> two identical machines DECStation 5000/240 with the same disks
>> >> >> >> (9.1GB). The mosaic version already compiled is 2.7b5. I
>> >> >> >> installed it on these machines at different times, within a few
>> >> >> >> weeks of difference.  The problem that I'm having is that the
>> >> >> >> one that I installed first (with 1.4.1) keeps giving me at the
>> >> >> >> bottom of the window a message saying:
>> >> >> >> 
>> >> >> >> "Can't open temporary file -- Serious Problem".
>> >> >> >> 
>> >> >> >> and
>> >> >> >> 
>> >> >> >> "Insufficient temporary disk space; could not transfer data"
>> >> >> >> 
>> >> >> >> Disk space is not really a problem in this machine, unless
>> >> >> >> mosaic is trying to write big stuff in the root partition where
>> >> >> >> I have 62k blocks. However I have the same in the machine that
>> >> >> >> is working OK. I couldn't find what could be different between
>> >> >> >> the two machines that makes this to happen.  Nor I don't know
>> >> >> >> where is mosaic trying to write in order to check in that area.
>> >> >> >> 
>> >> >> >> I will appreciate any pointers.
>> >> >> >> 
>> >> >> >> Dan