Skip to contentSkip to conversation

Ramdisks and tmpfs problems

DISCUSSION Geoffrey Gallaway 5 participants 15 messages Apr 9, 2002 – Apr 11, 2002

lore
Share & tools
lore

Geoffrey Gallaway

author
#0 lore raw

Hello,

I am attempting to create a central NFS server with a single slackware 8 installation that many boxes can use as their root disks. I got bootp kernel level autoconfiguration working and the test box sucessfully mounts the root (/) NFS share. I'm using floppy disks with kernels on diskless machines.

The problem occurs for /var, /tmp and /etc. Because each machine will need it's own /var, /tmp and /etc I've been trying to create a ramdisk or tmpfs filesystem for those partitions on each box. I've been using the system initialization scripts to setup these directories and dynamically rewrite important files (HOSTNAME, etc) in /etc.

Originally I started playing with ram disks but when I try to create a new ramdisk with "mke2fs /dev/ram0 16384" mke2fs says:
mke2fs: Filesystem larger then apparent filesystem size. Proceed anyway? (y,n) y
Warning: could not erase sector 2: Invalid arguement
Warning: could not erase sector 0: Attempt to write block from filesystem resulted in short write
mke2fs: Invalid arguement zeroing block 16320 at end of filesystem

So no go with ram disks (this is kernel 2.4.18 on a 3 gig RAM dual PIII 1gig, BTW). So now to try tmpfs. Since I need to copy the existing files in /etc off to tmpfs I have to create a "temporary" tmpfs, copy /etc off to it then create another tmpfs on top of the existing /etc and copy from the "temporary" tempfs back to the new /etc. I came up with the following commands:
mount -w -n -t tmpfs -o defaults tmpfs /mnt
cp -axf /etc /mnt
mount -w -t tmpfs -o defaults tmpfs /etc
cp -axf /mnt/etc/* /etc/
umount /mnt
# -- Reapeat for /var and /tmp --

Again, I put these commands in slackware's init scripts and it looks like everything is working fine until the login prompt appears, at which time the machine immediatly uncleanly reboots, eveytime without fail.

Anyone know what could be going on? I'm out of options as far as RAM-based filesystems. :)

Thanks,
Geoffeg

#1 lore raw
Quoted 10 lines · Geoffrey Gallaway

...
Originally I started playing with ram disks but when I try to create a new ramdisk with "mke2fs /dev/ram0 16384" mke2fs says:
mke2fs: Filesystem larger then apparent filesystem size. Proceed anyway? (y,n) y
Warning: could not erase sector 2: Invalid arguement
Warning: could not erase sector 0: Attempt to write block from filesystem resulted in short write
mke2fs: Invalid arguement zeroing block 16320 at end of filesystem

Try omitting the `16384' option - let mke2fs work out the size.

author
#2 lore raw
In reply to Geoffrey Gallaway

I tried that too, mke2fs says:
mke2fs: Device size reported to be zero. Invalid partition specified, or a partition table wasn't reread after running fdisk, due to a modified partition being busy and in use. You may need to reboot to re-read your partition table.

Quoted 19 lines · Andrew Morton
Quoted 10 lines · Geoffrey Gallaway

...
Originally I started playing with ram disks but when I try to create a new ramdisk with "mke2fs /dev/ram0 16384" mke2fs says:
mke2fs: Filesystem larger then apparent filesystem size. Proceed anyway? (y,n) y
Warning: could not erase sector 2: Invalid arguement
Warning: could not erase sector 0: Attempt to write block from filesystem resulted in short write
mke2fs: Invalid arguement zeroing block 16320 at end of filesystem

Try omitting the `16384' option - let mke2fs work out the size.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#3 lore raw
In reply to Geoffrey Gallaway
Quoted 5 lines · Geoffrey Gallaway

I am attempting to create a central NFS server with a single slackware 8 installation that many boxes can use as their root disks. I got bootp kernel level autoconfiguration working and the test box sucessfully mounts the root (/) NFS share. I'm using floppy disks with kernels on diskless machines.

Hi there! I've done this. I'm sitting on one of such diskless boxen now. (actually, it has 2 disks, one is a 1.2G IDE turned into "diskette" for home <-> work data transfer, other is *ugh* an NT installation).

Quoted 5 lines

The problem occurs for /var, /tmp and /etc. Because each machine will need it's own /var, /tmp and /etc I've been trying to create a ramdisk or tmpfs filesystem for those partitions on each box. I've been using the system initialization scripts to setup these directories and dynamically rewrite important files (HOSTNAME, etc) in /etc.

[snip]

Looks like stuff for Al Viro. Consider mailing him with a report (kernel/GCC version, symptoms etc).

Quoted 6 lines

mount -w -n -t tmpfs -o defaults tmpfs /mnt
cp -axf /etc /mnt
mount -w -t tmpfs -o defaults tmpfs /etc
cp -axf /mnt/etc/* /etc/
umount /mnt
# -- Reapeat for /var and /tmp --

Erm... just make a /etc_template, and you'll eliminate one cp. --
vda

#4 lore raw
In reply to Geoffrey Gallaway
Quoted 4 lines · Geoffrey Gallaway

So no go with ram disks (this is kernel 2.4.18 on a 3 gig RAM dual PIII 1gig, BTW). So now to try tmpfs. Since I need to copy the existing files in /etc off to tmpfs I have to create a "temporary" tmpfs, copy /etc off to it then create another tmpfs on top of the existing /etc and copy from the

Quoted 8 lines

"temporary" tempfs back to the new /etc. I came up with the following commands:
mount -w -n -t tmpfs -o defaults tmpfs /mnt
cp -axf /etc /mnt
mount -w -t tmpfs -o defaults tmpfs /etc
cp -axf /mnt/etc/* /etc/
umount /mnt
# -- Reapeat for /var and /tmp --

Wouldn't this be easier?

mount -t tmpfs none /dev/shm
cp -axf /etc/* !$
mount --bind /dev/shm /etc

#5 lore raw
In reply to Geoffrey Gallaway
Quoted 14 lines · Sean Hunter
Quoted 4 lines · Geoffrey Gallaway

So no go with ram disks (this is kernel 2.4.18 on a 3 gig RAM dual PIII 1gig, BTW). So now to try tmpfs. Since I need to copy the existing files in /etc off to tmpfs I have to create a "temporary" tmpfs, copy /etc off to it then create another tmpfs on top of the existing /etc and copy from

Quoted 8 lines

the "temporary" tempfs back to the new /etc. I came up with the following commands:
mount -w -n -t tmpfs -o defaults tmpfs /mnt
cp -axf /etc /mnt
mount -w -t tmpfs -o defaults tmpfs /etc
cp -axf /mnt/etc/* /etc/
umount /mnt
# -- Reapeat for /var and /tmp --

Quoted 5 lines

Wouldn't this be easier?

mount -t tmpfs none /dev/shm
cp -axf /etc/* !$
mount --bind /dev/shm /etc

/dev is for devices, why do you use it for mounting filesystems? I use /mnt/xxx or custom top-level dirs for mounts.

For example, I have /.share mounted to common NFS storage, /.local mount --bind'ed to local (i.e. per-workstation) storage, /mnt/auto is for automounter (local disk access, SMB etc) and symlinks:
/usr -> /.share/usr
/home -> /.share/home
...
/tmp -> /.local/tmp
/var -> /.local/var
...

This works just fine for me.
--
vda

#6 lore raw
In reply to Geoffrey Gallaway
Quoted 8 lines · Denis Vlasenko
Quoted 5 lines · Sean Hunter

Wouldn't this be easier?

mount -t tmpfs none /dev/shm
cp -axf /etc/* !$
mount --bind /dev/shm /etc

/dev is for devices, why do you use it for mounting filesystems?

Normally yes, but the tmpfs provides posix shared memory semantics and thus /dev/shm is the "normal" place to mount it. Don't blame me.

Sean

#7 lore raw
In reply to Geoffrey Gallaway

Hi Sean,

Quoted 5 lines · Sean Hunter
Quoted 1 line

/dev is for devices, why do you use it for mounting filesystems?

Normally yes, but the tmpfs provides posix shared memory semantics and thus /dev/shm is the "normal" place to mount it. Don't blame me.

Yes, and he does not want to use it for POSIX shared mem, but as a local filesystem. So he should mount it where he needs it and definitely not misunse the posix mount for different things.

Greetings
Christoph

author
#8 lore raw

Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway

I finally found the problem, which appears to be a combination of things:

Multiple tmpfs mounts and SMP.

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

If I can help to nail down this (apparent) bug more, please let me know.

Thanks,
Geoffeg

Quoted 49 lines · Geoffrey Gallaway

Hello,

I am attempting to create a central NFS server with a single slackware 8 installation that many boxes can use as their root disks. I got bootp kernel level autoconfiguration working and the test box sucessfully mounts the root (/) NFS share. I'm using floppy disks with kernels on diskless machines.

The problem occurs for /var, /tmp and /etc. Because each machine will need it's own /var, /tmp and /etc I've been trying to create a ramdisk or tmpfs filesystem for those partitions on each box. I've been using the system initialization scripts to setup these directories and dynamically rewrite important files (HOSTNAME, etc) in /etc.

Originally I started playing with ram disks but when I try to create a new ramdisk with "mke2fs /dev/ram0 16384" mke2fs says:
mke2fs: Filesystem larger then apparent filesystem size. Proceed anyway? (y,n) y
Warning: could not erase sector 2: Invalid arguement
Warning: could not erase sector 0: Attempt to write block from filesystem resulted in short write
mke2fs: Invalid arguement zeroing block 16320 at end of filesystem

So no go with ram disks (this is kernel 2.4.18 on a 3 gig RAM dual PIII 1gig, BTW). So now to try tmpfs. Since I need to copy the existing files in /etc off to tmpfs I have to create a "temporary" tmpfs, copy /etc off to it then create another tmpfs on top of the existing /etc and copy from the "temporary" tempfs back to the new /etc. I came up with the following commands:
mount -w -n -t tmpfs -o defaults tmpfs /mnt
cp -axf /etc /mnt
mount -w -t tmpfs -o defaults tmpfs /etc
cp -axf /mnt/etc/* /etc/
umount /mnt
# -- Reapeat for /var and /tmp --

Again, I put these commands in slackware's init scripts and it looks like everything is working fine until the login prompt appears, at which time the machine immediatly uncleanly reboots, eveytime without fail.

Anyone know what could be going on? I'm out of options as far as RAM-based filesystems. :)

Thanks,
Geoffeg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#9 lore raw
In reply to Geoffrey Gallaway
Quoted 5 lines · Christoph Rohland

Hi Sean,

Quoted 2 lines · Sean Hunter
Quoted 1 line

/dev is for devices, why do you use it for mounting filesystems?

Quoted 7 lines
Quoted 3 lines

Normally yes, but the tmpfs provides posix shared memory semantics and thus /dev/shm is the "normal" place to mount it. Don't blame me.

Yes, and he does not want to use it for POSIX shared mem, but as a local filesystem. So he should mount it where he needs it and definitely not misunse the posix mount for different things.

The whole point was that he was doing extra copies and mount/unmounts that he
didn't need. He couldn't just mount it in /etc/ in the first place because he
needed to copy stuff from the underlying fs that was there onto the tmpfs.

point -------------------------->
<------------- Christoph Rohland

Which is why I proposed two mounts:

(1) A mount under /dev/shm reflecting its nature and role as providing posix shared mem (convenient because its not /etc where he already _has_ files)

(2) A bind mount under /etc reflecting its nature and role as providing a ram-based file system (convenient because that's where he actually wants the fs to be)

I just suggested that by mounting it what has been established as the canonical place for mounting tmpfs and using a bind mount he doesn't need the extra copies/mounts.

Sheesh. Next thing you'll be asking if a filesystem can have buddha nature.

Sean "Mu" Hunter

#10 lore raw

Re: Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway

Just a data point: I have been using multiple tmpfs bind mounts for some time on smp without this problem.

none on /dev/shm type tmpfs (rw,nosuid,nodev,mode=1777,size=256M) /dev/shm on /tmp type none (rw,bind)
/dev/shm on /usr/tmp type none (rw,bind)

Never had a reboot fail for this reason.

Sean

Quoted 17 lines · Geoffrey Gallaway

I finally found the problem, which appears to be a combination of things:

Multiple tmpfs mounts and SMP.

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

If I can help to nail down this (apparent) bug more, please let me know.

Thanks,
Geoffeg

author
#11 lore raw

Re: Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway

What kernel version are you using on those smp+multi tmpfs boxes? What hardware?

Geoffeg

Quoted 35 lines · Sean Hunter

Just a data point: I have been using multiple tmpfs bind mounts for some time on smp without this problem.

none on /dev/shm type tmpfs (rw,nosuid,nodev,mode=1777,size=256M) /dev/shm on /tmp type none (rw,bind)
/dev/shm on /usr/tmp type none (rw,bind)

Never had a reboot fail for this reason.

Sean

Quoted 12 lines · Geoffrey Gallaway

I finally found the problem, which appears to be a combination of things:

Multiple tmpfs mounts and SMP.

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

Quoted 5 lines

If I can help to nail down this (apparent) bug more, please let me know.

Thanks,
Geoffeg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#12 lore raw

Re: Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway
Quoted 1 line · Geoffrey Gallaway

What kernel version are you using on those smp+multi tmpfs boxes?

As of this morning, 2.5.7. Before that 2.4.{17,18,19-pre*ac*} for some months.

Quoted 2 lines

What
hardware?

Dual pentium III (Katmai)

sean@henry:~$ lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02)
00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 04)
00:09.1 Input device controller: Creative Labs SB Live! (rev 01)
00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05)
00:0c.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 06)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)

All scsi disks. IDE cd-writer. More-or-less redhat 7.x distro with most of the interesting daemons replaced, and some legacy cruft still intact.

I don't use ACPI or devfs or framebuffer console, not that any of those should affect this.

Sean

Quoted 45 lines

Geoffeg

Quoted 27 lines · Sean Hunter

Just a data point: I have been using multiple tmpfs bind mounts for some time on smp without this problem.

none on /dev/shm type tmpfs (rw,nosuid,nodev,mode=1777,size=256M) /dev/shm on /tmp type none (rw,bind)
/dev/shm on /usr/tmp type none (rw,bind)

Never had a reboot fail for this reason.

Sean

Quoted 14 lines · Geoffrey Gallaway

I finally found the problem, which appears to be a combination of things:

Multiple tmpfs mounts and SMP.

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

If I can help to nail down this (apparent) bug more, please let me know.

Quoted 8 lines
Quoted 3 lines

Thanks,
Geoffeg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#13 lore raw

Re: Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway
Quoted 11 lines · Geoffrey Gallaway

I finally found the problem, which appears to be a combination of things:

Multiple tmpfs mounts and SMP.

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

Yes, sounds like race. It seems locking isn't quite right in tmpfs.

BTW, I'd like to know why do you want to use temporary storage (tmpfs/shm/ramdisk) for /var and /etc? In 'normal' Unix (i.e. not a special setup like computing farm) they are expected to survive reboot. Only /tmp is volatile. You want to keep per-workstation config files (/etc) and data (/var) across reboot, right?

Since my workstations aren't overstuffed with RAM, I use server supplied storage for everything. If I will have a multigig RAM box someday, I'll use tmpfs *only* for /tmp.
--
vda

#14 lore raw

Re: Update - Ramdisks and tmpfs problems

In reply to Geoffrey Gallaway

Hi Denis,

Quoted 10 lines · Denis Vlasenko
Quoted 8 lines

I am using a Dual Intel PIII 1Ghz box. When I use a SMP kernel AND do multiple tmpfs mounts (mount --bind /dev/shm/etc /etc; mount --bind /dev/shm/var /var) the machine goes into a reset loop. HOWEVER, when I use a non-SMP kernel and still do multiple tmpfs mounts OR when I use a SMP kernel and do only one tmpfs mount, the machine boots fine. Every once in a while (1 out of 20 times?) the machine would boot fine with a SMP kernel and multiple tmpfs mounts. Is this a timing issue?

Yes, sounds like race. It seems locking isn't quite right in tmpfs.

I am not sure. Could also be bad ram which only triggers under higher load. I never had instant reboots on my machines due to races, but only when I had bad DIMMs.

I also have multiple tmpfs instances on my 8-way test box where I developed and tested tmpfs.

But you could be right. Unfortunately I do not have the time to investigate further.

Greetings
Christoph