X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C863B2.9BB625CF@onstor-exch02.onstor.net>; Wed, 30 Jan 2008 19:40:14 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: question about device files used for boot-up by diskliess clients
Date: Wed, 30 Jan 2008 19:40:14 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E080585F6@onstor-exch02.onstor.net>
In-Reply-To: <04da01c863b2$490c4ad0$664d7e0a@glasshousetech.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: question about device files used for boot-up by diskliess clients
Thread-Index: AchjslfK4GS9jMKJRWmSKvYi/OM25AAADh6g
From: "Jobi Ariyamannil" <jobi.ariyamannil@onstor.com>
To: "Michael Tracy (Glasshouse)" <mtracy@css.glasshouse.com>,
	"dl-cstech" <dl-cstech@onstor.com>

Please see my recent update in defect TED00022007.

-----Original Message-----
From: Michael Tracy (Glasshouse)=20
Sent: Wednesday, January 30, 2008 6:38 PM
To: dl-cstech
Subject: question about device files used for boot-up by diskliess
clients

Hi all
Customer asked a question I can find no data on
Michael
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
First, some background on our environment. We have a variety of diskless

Linux systems which boot via NFS. That means that at boot time, the
diskless=20
systems use an NFS filesystem as their root filesystem. We have been
using rootfs:/rootfs as a repository for such filesystems. These
filesystems=20
have all the things normal filesystems do, including device files.

Device files are created with a mknod utility which sets major and minor

numbers for the device. These major and minor numbers have special
meaning=20
to the linux kernel and allow it use of any and all physical and virtual

devices on
the systems. In this case, the device files came with the filesystems
from=20
our vendors.

Today we noticed that the diskless systems were not booting. It turns
out=20
that the device files on the filesystem have incorrect major and minor=20
numbers.
Here is a sample:

root@daisy:/net/rootfs/rootfs# ls -l ./bishop/mvlcee3.1/dev | head
total 120
crw-rw---- 1 root root 0, 0 Nov 20 2004 atibm
crw-rw---- 1 root root 0, 0 Nov 20 2004 audio
crw-rw---- 1 root root 0, 0 Nov 20 2004 audio1
crw-rw---- 1 root root 0, 0 Nov 20 2004 audio2
crw-rw---- 1 root root 0, 0 Nov 20 2004 audio3
crw-rw---- 1 root root 0, 0 Nov 20 2004 audioctl
crw------- 1 root root 0, 0 Nov 20 2004 bootimg
crw------- 1 root root 0, 0 Nov 20 2004 console

Here is a sample of device files which have not had their major and
minor=20
device numbers set to 0 and 0:

root@daisy:/net/rootfs/rootfs# ls -ld /dev/sd* | head
brw-rw---- 1 root disk 8, 0 Jan 20 08:22 /dev/sda
brw-rw---- 1 root disk 8, 1 Jan 20 08:22 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jan 20 08:22 /dev/sda2
brw-rw---- 1 root disk 8, 3 Jan 20 08:22 /dev/sda3
brw-rw---- 1 root plugdev 8, 16 Jan 20 08:22 /dev/sdb

The files on rootfs:/rootfs were all fine before the weekend.

My question to onstor support: Is this an artifact of the crash on
Saturday=20
morning or of the offline eek we ran on this filesystem on Sunday?

More importantly, should I be able to trust any of the data on that=20
filesystem?


