Nuxified GNU/Linux Help Forums - CD-ROMs - Comments

Is your cdrom hda or

tbuitenh — Sun, 22 Apr 2007 14:49:02 +0200

Is your cdrom hda or hdb?
Also, you're trying to mount a cdrom as read-writable (rw)???

I just tried mount -t

shengchieh — Sun, 22 Apr 2007 04:58:17 +0200

I just tried

mount -t iso9660 /dev/hdb1 /mnt/cdrom -o rw,omask=000

same with hdb6 or hdb instead of hdb1.

I get a message saying

[root@localhost rscheng]# mount -t iso9660 /dev/hdb1 /mnt/cdrom -o rw,omask=000
mount: /dev/hdb1 already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hdb1 is mounted on /
[root@localhost rscheng]# mount -t iso9660 /dev/hdb6 /mnt/cdrom -o rw,omask=000
mount: /dev/hdb6 already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hdb6 is mounted on /home
[root@localhost rscheng]# mount -t iso9660 /dev/hdb /mnt/cdrom -o rw,omask=000
mount: /dev/hdb already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hda is already mounted on /mnt/cdrom
[root@localhost rscheng]#

when I device:konqueror

I see

CD-ROM (hda) .... 0B Mounted CD-ROM

but I put a disc in and double-click the link, I get

no items - no folder [never mind]

It went thru?!? I'm copyied the disk. Strange?!?
Any clue on what is happening.

Sheng-Chieh

asynchronous writing speed

tbuitenh — Wed, 04 Apr 2007 10:17:35 +0200

a thing wrote:

Asynchronous writing means that not everything is written right away, but when the best time occurs. This speeds up writing (most of the time—I've no idea why).

For disks, waiting a while and collecting the data means the data can be ordered such that it can be written in one sweep of the arm.

Flash memory can't be written one byte at a time, it must be written in large blocks. This causes a problem similar to filesystem fragmentation, which is less likely to happen if data is written bursts larger than those blocks. Furthermore, writing a block of flash takes a long time, so it's better to write a block once than it is to write it a few times.

Also, some programs will write something, and write to the same location again very soon. Doing that in a cache in RAM is much faster than on disk or flash.

Finally, asynchronous writing means the program doesn't have to wait for the real write to finish, so response time will be better. That's not the same thing as higher writing speed, though. In the case where a program writes a large amount of data, in the right order, and then doesn't access the same data again, a synchronous write would be slightly faster (no copying data around in RAM).

suggestions

a thing — Wed, 04 Apr 2007 06:34:48 +0200

I don't think we've ever had someone submit an article as the first thing they put on this site, but thanks. I hadn't heard of the -l option before.

I made some formatting changes in your article (replacing -- with —, putting titles in <h2> elements, capitalizing CD-ROM (It's an acronym.)), although I haven't made any changes to the meaning.

Now time for ACCâ„¢, a thing's Candid Critcismâ„¢:

You might want to add a note that device naming schemes differ between kernels. If you use Mach or a BSD, this part of the tutorial doesn't apply.

Ending directory names in a slash will help make it clearer that they're directories, not normal files.

Using "file" instead of "cat" on the USB device to find if it exists would work without not fill your console with garbage.

Things can be combined in one directory with UnionFS (Ionno how to do this though, I've never needed it).

The reason pulling a device out by force is bad is because it's mounted asychronously by default. This can be controled with the sync and async options. Asynchronous writing means that not everything is written right away, but when the best time occurs. This speeds up writing (most of the time—I've no idea why). When you forceably take out the device, the best time for asynchronous writing may not have occured yet.

Samba isn't a protocol, it's an implementation of the SMB (Server Message Block) protocol.

Every filesystem, not just smbfs, has its own separate program called by mount.

libervisco, signitures should be attached to comments on things other than forums too.

Corrections welcome

dcroxton — Wed, 04 Apr 2007 04:12:34 +0200

ifb wrote:

Quote:

There is also an "autofs" option, which I gather is supposed to detect the filesystem for you automatically, but I've never gotten it to work (nor have I had much need for it).

Newbe assumptions are sometimes very funny (No offence)

Even though I've been using Linux for 4 years -- 3 of them almost exclusively -- and I have managed to accomplish a lot of things that baffled me at first, I still feel like a newbie. I wrote this article because I had finally managed to figure out how to do what I needed with mounting, not because I felt like an expert.

I almost mentioned in the article that corrections and additions were welcome. Perhaps some time I will re-write it with the things I have learned from these comments.

Sincerely,
Derek

smbfs

ifb — Tue, 03 Apr 2007 11:20:11 +0200

Quote:

Actually, there is a separate mount command, "smbmount," just for Windows shares, but you don't use it. Instead, when you mount an smbfs filesystem, the mount command calls smbmount for you.

Note that as far as I could see, on Ubuntu the "smbmount" command isn't installed by dafult, which causes some strange errors when trying to mount Windows shares.
To enable "smbmount" one needs to install the "smbfs" package e.g. run
sudo aptitude install smbfs
on the command-line, or simply select it in Synaptic.

autofs

ifb — Tue, 03 Apr 2007 11:10:40 +0200

Quote:

There is also an "autofs" option, which I gather is supposed to detect the filesystem for you automatically, but I've never gotten it to work (nor have I had much need for it).

Newbe assumptions are sometimes very funny (No offence)
Actually autofs is used with the automount deamon (installed by the "autofs" package in Debian/Ubuntu) to allow for automatic (un)mounting of filesystems.
For example, you can set it up to automatically mount a shared directory over the network when you go into the /netshares/myserver/shared_files directory (directory names given are just for example).
In fact the "autofs" package includes some scripts to enable things like automatically mounting every windows share on the network by going into /smb/<hostname>/<sharename> or every NFS (unix) share by going into /net/<hostname>/<export-path>
Autofs was made as a tool for sysadmins to enable users to mount stuff without having to enable "sudo" for them or even teach them what "mount" is...

With regard to auto-detecting the filesystem type you can use:
mount -t auto ...
or not specify "-t" at all and "mount" will try to detect the filesystem type, which it will get right in most cases (its a little more complicated then that actually, details are, as ususal, in the manpage...)

Quote: If you have trouble

ifb — Tue, 03 Apr 2007 10:37:49 +0200

Quote:

If you have trouble finding out which program is preventing an unmount, you can find it using lsof +D /the/directory/you/want/to/unmount. Note that this can take a while because it will look at all files in the directory and ask the kernel if any program opened them.

Actually, there is another command built just for the purpose of finding out who is currently using a perticualr file or filesystem (and thus preventing it from being unmounted)
That command is "fuser" e.g.
fuser /mnt/disk/mydir/myfile
To check which process is using the file "myfile" or
fuser -m /mnt/disk
To figure out which process is using a file on the filesystem mounted on /mnt/disk.
Note that the fuser command should probably be run as root (use sudo) to be useful.

,lfs

Anonymous — Mon, 02 Apr 2007 08:28:44 +0200

WOAH! Thanks!!! I was just reading this article for the hell of it, mainly to see if there was anything I didn't already know about shares and you've answered a question I hadn't even started looking for an answer for!!

Only this morning I discovered my remote samba share gzip backup script was dieing, I ran it manually and it kept dieing at exactly 2147483647 bytes. Now I know the cause of the problem and have the solution!

dcroxton wrote:

I will mention one other issue with Samba shares, because I ran into it recently and had a heck of a time finding the solution. Apparently, Samba is only set up to deal with files of up to 2GB, which is not usually a problem. Since I was trying to copy videos, however, it was an issue for me. The solution is to pass "lfs" as one of the options:

	mount -t smbfs //Windowscomp/sharedfolder /mywindowsdir -o username=myuser,password=mypassword,lfs

DDC - discs don't care.

reptiler — Sun, 01 Apr 2007 04:39:02 +0200

DDC - discs don't care. They are just containers, you can even record a CD with ext2 if you like, no problem at all.

there is no technical

free-zombie — Sun, 01 Apr 2007 00:57:01 +0200

there is no technical connection between FAT (which is vfat) and floopies, USB devices or memory cards. VFAT only means DOS formatted, which happens to be most common for these examples, but I have created ext2 partitions on USB sticks, and if you get a floppy image of a linux distribution, it will definately NOT be FAT formatted

In case you need a real

reptiler — Sat, 31 Mar 2007 09:40:14 +0200

In case you need a real device, which I, again, need for EasyLFS, you can use losetup to assign the file to a loopback-device.

losetup -f /testlfs.img
will enable the use of the next free /dev/loop-device, which can be checked beforehand by
losetup -f
If no device has been enabled before, this of course will be /dev/loop0.

losetup -d /dev/loop0
will clear the association and the loopback-device will become unusable.
This step can be skipped and integrated into unmounting by using -d with umount.

man umount wrote:

-d In case the unmounted device was a loop device, also free this
loop device.

mount iso files

Anonymous — Sat, 31 Mar 2007 04:55:31 +0200

one thing that took me a while to find out was the command for mounting ISO files,

mount -t iso9660 -o loop /isofile.iso /mount/point

I find myself using this command at least once a day.

Right, but it can be useful

reptiler — Fri, 30 Mar 2007 14:43:32 +0200

Right, but it can be useful for other things.
On my EasyLFS for example, the script is supposed to unmount the partition and then reboot, but it cannot really unmount because something is still running from that partition. So the scripts calls a lazy unmount and starts the reboot. The script will end then and, before the reboot really shoots off, or at least before it's done, the device will be properly unmounted.

For the USB-stick, at least it prevents new access to the device, and processes that currently work on it can still finish (or be killed if you like).

lazy unmount

tbuitenh — Fri, 30 Mar 2007 14:30:22 +0200

reptiler wrote:

You can also do a lazy unmount, which means that programms currently using the data from the mounted device can still do so until they are finished, but nothing new will have access.

umount -l mountpoint

Yes, but that's not very useful when you want to remove your usb stick...