Mounting a DVD or CD image virtually in Linux

Mounting a DVD or CD image (ISO file) virtually is trivial in linux. To do this you’ll need to have superuser permissions, in the example below I’m using the sudo command:

cfaber@sputnik:/dump$ mkdir ISO
cfaber@sputnik:/dump$ sudo mount -o loop DVD-IMAGE.ISO /dump/ISO
cfaber@sputnik:/dump$ df -h | grep loop
/dev/loop1             1.8G  1.8G     0 100% /dump/ISO

As we can see, mount was successful!

Use rsync to copy files faster, as well as showing progress

One of the commands that I find my self using almost everyday is rsync:

a fast and extraordinarily versatile file copying tool. It can copy locally, to/from another host
over any remote shell, or to/from a remote rsync daemon. It offers a large number of options that control
every aspect of its behavior and permit very flexible specification of the set of files to be copied. It is
famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending
only the differences between the source files and the existing files in the destination. Rsync is widely
used for backups and mirroring and as an improved copy command for everyday use.

Rsync finds files that need to be transferred using a “quick check” algorithm (by default) that looks for
files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as
requested by options) are made on the destination file directly when the quick check indicates that the
file’s data does not need to be updated.

In general, the following flags work great: -P (Progress), -a (archive mode), -v (be a little verbose).   When copying to an NFS share, it’s also a good idea to bandwidth limit your connection to some reasonable number. I’m copying via wifi and I know from extensive testing that I get around 15 to 25 megabytes a second copies to my NFS server. So to stay on the safe side I limit to just under 15 megabytes (150000 bytes). This can be done with the –bwlimit=BYTES flag.

 

cfaber@sputnik:/home/dump$ rsync -Pav --bwlimit=15000 data /home/hal/OpenNAS/.
sending incremental file list
data
    608,370,688  56%   14.65MB/s    0:00:31 

And so on.

The nice thing about this is that rsync will respect that bandwidth limit. Additionally the file being synced is checksummed for errors, so you can be sure that the destination file is identical to the source file.

Rsync is also available on windows within Cygwin however, it doesn’t respect, and can’t copy file permissions (from within a windows environment).

Multiple claimed blocks errors

So your file system has crashed… Upon running e2fsck against it you’re now seeing error such as:

Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 4195619:
167904376 167904377 167904378 167904379 167904380 167904381 167904382 167904383 167904384
167904385 167904386 167949296 167949297 167949298 167949299 167949300 167949301 167949302
167949303 167949304 167949305 167949306 

What does this all mean?

Well unfortunately for you this means that your file system has incurred major damage.

What’s happened is the inode structures around this part of the file system have been damaged to the extent that multiple inodes are claiming to own the same data blocks.

There is no way to really fix this without rolling back the file system or restoring from backup.

The inode (in the case above) which was damaged was 4195619. Some other inodes have already layed claim to the blocks listed above and now this inode is trying to also lay claim to them. Multiple inodes cannot claim the same blocks (unless of course we’re talking about special inodes such as hard links).

Sadly the inodes which were discovered before inode 4195619 could potentially be damaged and this inode could be fine. The only way to know for sure would be to dump the inode and it’s associated blocks out to a file, then verify that file based on a previous checksum you may have taken.

Adobe Lightroom 5.3 and crash on import

So yesterday the wife was complaining to me that her Adobe Lightroom installation was not working correctly.

The problem she was having had to do with importing files into Lightroom.

Basically what was going on was she would open Lightroom up, click on import, and then anything within the import window would result in lightroom crashing.

After some digging around on the intertubes I found what might be the problem. Apparently Lightroom doesn’t handle partially connected drives very well (or at all) such as phones (in her case, Samsung Galaxy Note 4).

After instructing her to disconnect her phone, poof the problem is gone!

I suspect if you’re having similar issues, be sure that all disks which present themselves to windows are fully connected and available prior to attempting to import.