Questions about the SSD Guide

[tashirosgt]

I have a few questions about the SSD guide http://forums.fedoraforum.org/showthread.php?t=277082

7/ Eliminate "Elevator" disk scheduler. [PERFORMANCE, RELIABILITY]

Rotating disks use the 'elevator' algorithm to schedule block access. This algorithm makes no sense for a SSD media where there are no cylinders and seek time is nearly constant.

Individual drives can use distinct scheduling algorithms by adding the following line to /etc/rc.d/rc.local
echo noop > /sys/block/sda/queue/scheduler

My understanding of /dev/... naming is that if you fiddle with your hardware and plug the SATA cables in different controllers, the SSD that was once /dev/sda could turn out to be /dev/sdb when you rebooted. Is there a version of the command echo noop > /sys/block/sda/queue/scheduler that uses the disk identifier instead of the /dev/sda type nomenclature?

ii) Write logs to a rotating drive.
An fstab entry similar to ....
/dev/sdb4 /var/log ext4 noatime 0 0
causes the device to be mounted on top of /var/log directory, however this mount will occur after rsyslog has already opened some log files. So after the mount (perhaps in /etc/rc.d/rc.local) it is necessary to send rsyslogd a SIGHUP signal to cause it to close and reopen log files.

/bin/kill -s HUP $(cat /var/run/syslogd.pid)

I'm curious where rsylog would write the log files if you didn't put the /bin/kill... command in rc.local. Would it create a /var directory somewhere?

This is probably a matter of understanding a very basic point about Linux filesystem handling. Suppose I have a filesystem mounted that has directory /var/X/Y. Suppose I then issue a mount command to mount a device at /var/X/Y. Do all subsequent attempts by the operating system to read and write to /var/X/Y use the newly mounted device? Or is there some scheme where the operating system trys the /var/X/Y on one of the devices and goes to the other device if the file operation fails?

[george_toolan]

Why do you want to be unfair?

The standard scheduler seems to be CFQ. See http://en.wikipedia.org/wiki/CFQ

Sata drives have a feature called NCQ. See http://en.wikipedia.org/wiki/NCQ

I wouln't expect any problems with /var/log if you mount it in /etc/fstab since additional drives are mounted immediately after the root file system.

So where does rsylog write the log before the root filesystem is mounted?

But why do you want tp buy an expensive SSD and then try not to use it at all cost?

For your mount experiments try something like:

# mkdir /mnt/temp
# echo "Hello" > /mnt/temp/word.txt
# cat /mnt/temp/word.txt 
Hello
# mount -t ext3 /dev/sdb1 /mnt/temp/
# cat /mnt/temp/word.txt 
cat: /mnt/temp/word.txt: No such file or directory
# echo "World" > /mnt/temp/word.txt
# cat /mnt/temp/word.txt 
World
# umount /mnt/temp 
# cat /mnt/temp/word.txt 
Hello

[tashirosgt]

Originally Posted by george_toolan

Why do you want to be unfair?

One of the time honored ways of answering the question "How do I do this?" on the internet is to reply "Why do want to do that?", so I grant that you are upholding a long tradition - the others being "You don't want to do that","You can't do that!","You're asking the wrong question".

It would be a great simplification if I didn't have to worry about elevator disk scheduling. I didn't keep track of SSD guide thread when it first appeared, so I don't know if there was a controversy about this in that thread.

The standard scheduler seems to be CFQ. See http://en.wikipedia.org/wiki/CFQ

I dont' understand the relation between "elevator scheduling" and CFQ. Are you suggesting that modern Linux distributions don't use "elevator" scheduling?

Sata drives have a feature called NCQ. See http://en.wikipedia.org/wiki/NCQ

Are you suggesting that a modern SSD may "counteract" any elevator scheduling?

I wouln't expect any problems with /var/log if you mount it in /etc/fstab since additional drives are mounted immediately after the root file system.

I wouldn't have suspected any either until I read the SDD guide.

So where does rsylog write the log before the root filesystem is mounted?

Yes, where? But my question about the general behavior of Linux filesystem handling is probably more important that this specific.

But why do you want tp buy an expensive SSD and then try not to use it at all cost?

My actual goals in making this new computer system are to make one that is quiet and lasts a long time. I don't really care if it is faster than my old systems. In fact, I'm putting a laptop hard drive in it instead of a desktop hard drive, only because of the noise considerations. I want to make some use of an SSD just to fool around with SSDs and with the hope that the fast SSD will somewhat compensate for the slow laptop drive. If the combination of drive types is as fast as my old systems, I'll be happy.

For your mount experiments try something like:
....

You suggest some good experiments, which I'll try if I have to. It's easier if someone just tells me! Right now, I'm just running the system with a live CD and investigating issues that I've mentioned in other recent threads.

[george_toolan]

You worry too much ;-)

It is virtually impossible to kill a ssd just by writing to it on a normal desktop machine.

But this doesn't necessarily mean it will last a long time. It could die for other reasons and these little buggers always have firmware issues.

[tashirosgt]

Originally Posted by george_toolan

It is virtually impossible to kill a ssd just by writing to it on a normal desktop machine.

So the SSD Guide http://forums.fedoraforum.org/showthread.php?t=277082 is obsolete? unnecessary?

It doesn't matter if it is. The questions I asked apply beyond the SSD guide.

------------

Edit: I installed FC 16 on a machine using the custom mount option. I mounted "/" on the SSD and "/var" on a laptop drive. If I boot from the recovery kernel I can unmount /var. (From the other kernel, I can't since it says that /var is busy.) After I unmount /var, there is still a directory /var in the directory tree. It only has a few KB of files in it. I created a text file in this /var. I rebooted. The textfile wasn't in the /var on the laptop drive. I unmounted that /var and the the other /var was accessible. It had the text file I created in it.

From that one test, when you mount a filesystem, it may replace an existing filesystem at the same place in directory tree. When you unmount it, the original one appears again. You don't get any error messages from the mount and unmount commands. (I don't know what happens if you do a whole series of mounts over mounts.)

Something in the install process does create a /var directory on the SSD and puts a small amount of data in it before the other /var gets mounted. I don't know whether this /var was created just by booting or whether it was something that only happens in an install.