The /dev/rdsk devices are character devices. These are used for low level manipulation of the corresponding slice's data a character at a time. The /dev/dsk devices are block devices. These are used for accessing the slice's data in blocks in a structured manner through a filesystem.
I need to figure out the hard drive name for a solaris box and it is not clear to me what the device name is. On linux, it would be something like /dev/hda or /dev/sda, but on solaris I am getting a bit lost in the partitions and what the device is called. I think that entries like /dev/rdsk/c0t0d0s0 are the partitions, how is the whole hard drive referenced?
If the drive is greater than 1TB, or if the drive has been used for ZFS, the drive will have an EFI label and slice 2 will NOT be the entire disk. With an EFI label, slice 2 is "just another slice". You would then refer to the whole disk by using the device name without a slice, e.g. c0t0d0.
I have moved disk0 from one Ultra1 to another Ultra1
Upon boot, the new machine is trying to fsck /dev/rdsk/c0t0d0s0
(dispite entry in /etc/vfstab to the contrary)The root password is given to attempt to fsck the disk manually.
The error message is that the device cannot be opened.
At this point, the filesystem is mounted read-only, so no
changes can be made.I have put the disk0 into another machine and run fsck, finding no
errors.I have mounted to the 2.6 intallation cdrom, then I can
fsck the disk or mount /dev/dsk/c0t0d0s0 to /a Can anyone help me bypass the fsck at boot?TIARudy
You could force the remount, but I'll bet you'll get a similar error.mount -o remount,rw /dev/dsk/c0t0d0s0 /What does 'format' show for installed disks?--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< Please move on, ...nothing to see here, please disperse >
upon entering the root password, fsck /dev/dsk/c0t0d0s0 (and rdsk)
says no device file found.format says no disk found.boot to the cdrom and I can fsck and mount and format shows the disk.
the device files seem to be there when c0t0d0s0 is mounted /a(also did touch of /a/reconfigure while I had c0t0d0s0 mounted at /a )
Rudy
Well although you say these are both Ultra 1's, it seems like there are
some differences between them. Are you certain you've inserted the
drive into the exact same slot and everything? I don't know why all the
devices aren't working for you.In my previous message where I suggested you could copy /dev from the
cdrom, you'd probably need to copy both /devices and /dev.I'd keep a backup of the old directories if you don't want this disk to
become even worse than it is.
In this hands-on assignment we will experiment with some of the samebenchmarks used in the LFS paper.This assignment should be done on an otherwise unused workstation that youhave root access to. Athena workstations are acceptable (the root password canbe found by typing tellme root at the athena prompt). To become root typesu at the athena prompt and give the root password when prompted.Step 0: Preparation You will need to collect some information aboutthe machine you are using before beginning the assignment: determine the name ofthe raw disk device for the machine's hard drive. On linux this will besomething like /dev/sda or /dev/hda. On Solaris (athena) machines it will besomething like /dev/rdsk/c0t0d0s3. You can find this info easily by looking atthe output of the df command which lists the available space on eachpartition. Note that df returns available space in terms of the number of(usually 1K) blocks free. Either pick a partition that corresponds to the wholedisk (/dev/rdsk/...s3 on Solaris or /dev/[hs]da on linux) or one that is atleast 64MB in size. Also determine the model number and vendor of the disk. Youmay find this information by scanning the output of the command dmesg onlinux machines or sysinfo on the Suns.You will need to build some test software to complete this assignment. Thissoftware is found here.Untar the source and build it with the following commands: athena% add -f gnu
athena% gtar zxvf lfs-0.0.tar.gz
athena% cd lfs-0.0
athena% ./configure
athena% gmake
Step 1: Raw Data Transfer Rate/Latency To begin this hands-onassignment we determine the maximum data rate and average latency of the fixeddisk attached to the machine we are using. We will measure disk performance byaccessing the disk in "raw" format. This avoids the overhead imposedby acessing the disk through the file system. Later we will compare theseresults to those obtained by accessing the disk via the file system.1.A Data Rate There are two ways to find the maximum data transferrate of your disk: 1) Using the supplied benchmarking program: bw. This program expects two arguments: the name of the raw disk device (collected above), and the number of megabytes to read from disk. Specify the -b option to measure the data transfer rate. The command must be run as root on most systems. Results are most reliable if at least 64 MB are read. Experiment with different sizes to find the true transfer rate. Example usage: athena# ./bw -b /dev/rdsk/c0t0d0s3 64 2) Using the dd and time commands. Type man dd for more details Example usage: time dd if=/dev/rdsk/c0t0d0s3 of=/dev/null bs=1024k count=64
1.B Latency Find the latency using the bw command (with the -loption): In this mode, bw expects two arguments: the name of the device and the number of trials to run. For each trial, bw will seek to a random location on disk and read a small amount of data. It will report the average latency to begin a read (this latency includes both the time to position the disk heads and the rotational latency). Increasing the number of trials will produce better results. Experiment until you are confident in your answer. Make sure that the specified partition is at least 100MB in size If the command returns an "invalid argument" error (especially on older Sun machines) try substituting "dsk" for "rdsk" in the device name. Example: athena#./bw -l /dev/rdsk/c0t0d0s3 1000
Step 2: LFS Benchmarks We will now run a version of the benchmarksfrom the LFS paper. The results of these benchmarks (as run by the authors) canbe seen in the graphs on pages 45 and 46 of the LFS paper. Please review section5.1 of the paper which describes these tests in detail.2.A First, run the small file benchmark using smallfb. Thisprogram expects two arguments. The number of files to create (10000 in thepaper) and the size of each file (1024 bytes in the paper). Run smallfbwith these values and report your results. This command may take a long time(minutes) to complete. You may experiment with lower values, but if you set thenumber of files too low you may end up testing your disk cache and not yourdisk. Note: make sure that you run this command from a directory whichresides on your local disk (smallfb will test the current working directory)."/var/tmp" is a good choice on most Athena machines. Do not run thiscommand from your home directory or another network file system. Also, make surethat the partition you run this command on has enough free disk space tocomplete the command (again, check with "df -k") Example usage: athena%./smallfb 10000 1024
Step 3: Analysis Given what you know about the (non-log-structured)file system running on your test machine, explain the performance of your filesystem on these benchmarks. Questions to consider: - What is the ratio of the actual bandwidth achieved in the small file benchmark to the raw bandwidth of the disk? In other words, are you able to take advantage of the raw performance of your disk? What accounts for the discrepancy? - What is the limiting factor in each of the two tests (large/small file benchmarks) - Would you expect the log file system perform better in these tests? Why? - Optional: Are there other aspects of the file system that can affect the performance of these tests? Those who tested on the Linux ext2 file system should consider the fact that ext2 relaxes the consistency guarantees of FFS by not synchronously writing meta-data (inodes, superblock, freelist etc.) to disk.
c80f0f1006