No, not Adam Deal… I learned from my Livonia teammates last week that the Unix team used to block off time on fridays sometimes to Drop Everything And Learn.  Well, since I have quite a lot to learn I’ve been dedicating a good portion of my monday and tuesdays as study time for Unix.  It’s been an excellent time to study though, it’s quiet out in the Rock Cottage lately.

I’ve been reading through a Bash scripting book for a few days now.  I already was familiar with quite a lot of what I’ve read so far, but what the book has been doing for me is filling in a lot of the finer details about bash that I’ve just never spent the time to read about.  It’s good though, I want to focus the same kind of intensity on this as I have in the past with VBScript and VMware ESX.

Technorati Tags: bash, Linux, Unix

Social Bookmark Links

Hide Sites

I’ve been noticing that there’s a bit of a performance issue with the new setup (Drobo on a Linux box using NTFS filesystem).  I guess I’m not completely shocked.  I mean, I am basically making a Linux box work with a Windows filesystem, and then also present it as a Windows share on the network (via Samba).  There’s bound to be some tweaking that has to occur.

So far the real bottleneck appears to be related to the NTFS-3G module that facilitates the communication between Linux and the NTFS filesystem on my Drobo.  The wife tried to copy 26 GB of video files over the network to the Drobo, and when I checked “top” on the server, there’s a “mount.ntfs-3g” process that was soaking up 88% CPU, and my load average was about 1.4 - 1.6 (on a dual proc system).

So, it looks like there’s quite a bit of overhead to getting Linux to fully interact with NTFS.  I really don’t want to go to EXT3 on this thing though.  Drobo Inc. claims they support it, but it still sounds like there’s issues with it.  I could just buy the Droboshare module that would basically put the Drobo on the network, but that eliminates me having all this fun with Linux and making it do my dirty work.

If I can find time this week, I might research this kernel module a little more to see if there’s some tweaking I can do to make it a little faster.

Technorati Tags: drobo, Linux, ntfs, ntfs-3g, Samba

Social Bookmark Links

Hide Sites

Wow, did I have a heck of a time nailing down a solution to get my Drobo to work in Linux and still meet all my requirements.  It previously was on a Windows 2003 server, but since I’m a Unix guy now…that doesn’t make sense anymore.  So I wanted to move it over to Linux, but I had to have a few conditions met:

1. The file system format had to be something that I could easily still move to a Windows box, and plug it in and it would work.  This is just in case my Linux box blows up, and the wife still needs access to the files on her Vista PC.  That limits me to FAT32 nd NTFS.
2. The front lights still need to work.  I’ve read that with EXT3 on the Drobo, it can’t properly evaluate drivespace use.  If you put data on, and the use lights go up…then you delete, the lights don’t change.
3. It needed to be able to be mounted into the filesystem and used with Samba without much difficulty.

I had originally wanted to convert it to FAT32 since that’s natively supported in Linux.  But, I later found out that would limit me to files no larger than 2GB in size.  That’s not possible because I have some TrueCrypt volumes and AVI files that are WAY larger than that.

Then I tossed around the idea of going to EXT3 on the Drobo, but that won’t work because I can’t move i back to Windows easily, and the front usage lights on the Drobo stop working.  Plus, I’m still unsure if removing and upgrading drives in the Drobo will function properly with the EXT3 filesystem, even though the latest firmwares are supposed to allow EXT3 to be supported.

So, decided to leave it in NTFS format (which it already was in), and try to find a way to make CentOS mount it with R/W capabilities.  After some Googling, I found out that a few packages (Fuse / NTFS-3G) was all that was needed to add this functionality.  After some wrestling with kernel versions, compiling, kernel module tweaking, etc..etc..  I finally got the Drobo to mount properly, and added it to /etc/fstab.

I’m still a bit worried about it, but so far I’m able to access everything.  Creates and deletes files/folders just fine.  Has ownership/group of root, and 777 for permissions (which is fine for me for now).  So, I created a Samba share for it, and headed on over to the wife’s Vista PC.  She already had a drive mapping pointed at \\drobolizer\drobo, so I opened it up and POOF!  The damn thing worked perfectly, as if nothing had changed.  Seemless!  On her side of things, she wouldn’t know it’s on a completely different OS now.  Share comes up the same to her.

Mission accomplished.  Now I have to setup some cron jobs to do backups on this thing.  Amanda maybe.

Technorati Tags: centos, drobo, ext3, fuse, Linux, ntfs-3g

Social Bookmark Links

Hide Sites

I learned a valuable lesson this morning while converting my main fileserver from WIndows 2003 to CentOS Linux this morning (at home).  I had set everything up, just did a net install and allowed it to create the LVM volume group and logical volumes.  Well, I changed my mind after the fact and wanted to rename the LV’s at least (looks like I’ll have to dismount to rename the VG).

Well, I did that and then went and changed /etc/fstab to reflect the new names, and rebooted.  Splat!  System wouldn’t boot.  Looked pretty obvious, I forgot to change my GRUB config.  So, I rebooted again, changed the line in GRUB boot to reflect the new root mount point, and everything booted fine.

Modified /boot/grub/grub.conf to fix it, and rebooted again.  Now everything was coming up ok, except that I was still getting an initial error stating that there was a volume that couldn’t be mounted or checked for resume.  Kept naming LogVol01 (which was my swap volume).

Did some digging and found out that there was still references in the initial ramdisk that pointed to the old LV name.  Found some docs on how to edit it manually, and then also how to use “mkinitrd” command to just recreate it.  Did that, and now everyting is running fine.

Great lessons on LVM and also the boot process learned there.

Technorati Tags: initrd, logical volume, LVM, mkinitrd, volume group

Social Bookmark Links

Hide Sites