IPFire

Linux ‘screen’ command

0
13 years
by in General, HTPC, IPFire, networking

Just a quick note about an awesome tool I’ve discovered on my travels.

The ‘screen‘ command in a linux shell.

This neat little tool allows you to run a remote shell (via SSH in my case) and run a command so that it doesn’t die after you exit the SSH session.

Normally when you exit an SSH session while a command is being run you will kill any processes being run by that session. With screen, you basically tell it to leave that particular session in the background (running) and you can come back to it at any time and check on its progress.

I’ve found it particularly useful when I’m using Rsync to dump the files from one computer to another (as in my current predicament.

So basically your essential commands are:

localhost@user:$ screen

This makes a new screen so you are given a new shell in which to type any commands you need to run in the background.

localhost@user:$ screen -ls

This will give you a list of current screen sockets open. Note the socket number so you can get back to the screen you want.

localhost@user:$ screen -r [screen socket number]

This command will reattach/restore the screen you had running to the front so that you can check on it’s progress. If at this point you exit the shell the session will still remain and you can use the same command to restore it again.

 

Once you are finished, just type exit and it should kill the socket and drop back to the standard shell.

If for whatever reason it doesn’t drop the socket (check with screen -ls) you can either leave it (I doubt it would use much memory anyway) or use the command screen -wipe and that will destroy all sockets that have been made.

So that’s it. What a useful tool, and very easy to use.

As always with Linux, it has many more options than described here, so you can check the man pages on it (man screen) or just screen –help will give you most of what you’ll ever need.

Later.

Media Drive saga continues..

0
13 years
by in Desktop, General, HTPC, IPFire, networking, samba

A couple of months ago I did something really stupid and installed an OS onto the wrong hard drive (due to sata drives being automatically moved to /dev/sda, and maybe a little stupidity on my part). So after much time wasting and much frustration, I ended up getting another 2TB drive and dumping what files I recovered onto it.

Now that’s all well and good but it appears that I have a fair amount of corruption on the recovered files. As I encounter corrupted files I can note and re-encode them later from their original Blu-ray/DVD sources.

Anyways that isn’t my primary issue at the moment; After I duplicated the recovered files off the original NTFS drive I wiped it and reformatted as ext4 so as to ensure I didn’t encounter issues with the linux implementation of NTFS (nfts-3g) – which I have encountered before. So that went smoothly, I Rsync’d the files back from the media PC (where I installed the new drive) and shared it in SAMBA. All of which happened relatively smoothly, which is strange for me, and I was finished by the next day.

Problem.

After a while I noticed that a transfer from the SAMBA share would never successfully complete and would seem to fail at random times (but usually the same place). I assume this has something to do with the corrupt files that occupy the drive but since I have no real fool proof way of figuring out which are corrupt and which aren’t (codecs are pretty damn good at guessing and the rebuilding pieces on the fly) , I’m stuck in a bit of a bind.

In the end I decided to reformat the EXT drive as XFS owing to its great track record in delivering media files and handling big HDD sizes. Luckily, IPFire has an addon for XFS support and even includes tools to make the XFS filesystem and make an XFS partition.

As I type, i’m running Rsync on the router, copying the files of the media-pc (it does take a while copying 1.6TB of data =D) over to the newly created XFS drive.

That all for now, hopefully this works and I can report on the performance figures of the XFS file system and if it solved my problems.

Later.

Windows – Linux Networking

0
13 years
by in Desktop, General, IPFire, networking, samba

So a few weeks ago I installed IPFire on my router primarily to enable me to put in an NTFS drive and share it via SAMBA.

I’ve only now got around to actually measuring how fast it actually transfers; not so good.

But first I did an IPerf test to check my actual throughput, with interesting results:

When the Router was Client I got 476Mbps or 59.5MB/s
Now with my Windows 7 machine as the client I got 268Mbps or 33.5MB/s

There’s something weird going on there.

Anyway on to the SAMBA results:

Source of file: /tmp (ext4 drive)

Router -> Desktop I got 20-21MB/s
Desktop -> Router I got 15-17 MB/s

Source of file:  /mnt/media (ntfs drive)

Router -> Desktop I got 15 MB/s
Desktop -> Router I got 8-9 MB/s

Funny thing about all this: I have no idea what conclusions I can draw from the data provided. It appears that the slowest transfer occurs when I try copying a file from my desktop machine to the media drive on the router. Why? Not a clue. It really doesn’t make much sense to me. Possibly it’s the NTFS driver, maybe the HDD has something wrong, perhaps the mount point isn’t configured right.
One thing I can be sure of is that the problem happens primarily when transferring from my desktop machine, to the router. Guess it’s gonna be trial and error

« Previous
Next »
Go to Top