NAS Remote Side of a Mirror

NAS Remote Side of a Mirror

[adfas asd]

I'm looking at setting up my RAID mirrored array so that one side of the mirror is in the HTPC and the other is NASsed in the garage, in case of theft or fire.

I am concerned about the boot process though, as the NASsed side will not be available until the network comes up.  Will the array be able to be patient for that and include that side once it comes up, and run not degraded?

What if I lose my local side of the mirror?  Is failover possible to the NAS side?  (Assuming a separate boot disk with everything except /home, which is on the array)

The only other technology I am aware of which can remote drives at distance is fibrechannel, and that's too expensive, so it seems I'm stuck with GB ethernet.  Are there in fact any other options?

Is it possible to bring up ethernet early in the boot process with initrd.img?

Has anyone actually done any of this?


      

Re: NAS Remote Side of a Mirror

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

On Mon Oct 05, 2009 at 08:37:37AM -0700, adfas asd wrote:

> I'm looking at setting up my RAID mirrored array so that one side of
> the mirror is in the HTPC and the other is NASsed in the garage, in
> case of theft or fire.
> 
> I am concerned about the boot process though, as the NASsed side will
> not be available until the network comes up.  Will the array be able
> to be patient for that and include that side once it comes up, and run
> not degraded?
> 
The network can be brought up from within the initrd, so there's no need
for the array to wait (that's even more trivial if you just have /home
on the array as you suggest below).  Alternately, you could use
write-intent bitmaps, in which case the resync should be very quick (you
may want these anyway - depends how reliable the network connection and
NAS is).

> What if I lose my local side of the mirror?  Is failover possible to
> the NAS side?  (Assuming a separate boot disk with everything except
> /home, which is on the array)
> 
Yes (providing you have the array set up properly so the remote holds a
complete data copy).

> The only other technology I am aware of which can remote drives at
> distance is fibrechannel, and that's too expensive, so it seems I'm
> stuck with GB ethernet.  Are there in fact any other options?
> 
Not that I've used, no.

> Is it possible to bring up ethernet early in the boot process with
> initrd.img?
> 
Yes - this is pretty common for network booting.

> Has anyone actually done any of this?
> 
I've not anyway.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: NAS Remote Side of a Mirror

[adfas asd]

--- On Tue, 10/6/09, Robin Hill <robin@robinhill.me.uk> wrote:
> > I am concerned about the boot process though, as the
> NASsed side will
> > not be available until the network comes up. 
> Will the array be able
> > to be patient for that and include that side once it
> comes up, and run
> > not degraded?
> > 
> The network can be brought up from within the initrd, so
> there's no need
> for the array to wait (that's even more trivial if you just
> have /home
> on the array as you suggest below).  Alternately, you
> could use
> write-intent bitmaps, in which case the resync should be
> very quick (you
> may want these anyway - depends how reliable the network
> connection and
> NAS is).

Wow, this is good news.  I'll do some research.

It's a freaky quantum world, when you don't even need a partition...

Ya have write-intent bitmaps enabled already, thanks.




      

Re: NAS Remote Side of a Mirror

[adfas asd]

OK, say I wanted to build this remote NAS box myself, rather than spending $750 for a Qnap. (http://qnap.com/pro_detail_feature.asp?p_id=110)  I find a good case, power supply, micro mobo, and cage, and install Linux and NX (remote desktop) on it.
 
I need to share those drives over GbE with minimal software intervention. I'm not about to use bloatware like NFS or Samba. And sshfs or an SSH tunnel could not keep up the speeds I'd need. How do you suppose Qnap shares those drives? And provides all those other services?
 
So looking at Qnap's update, it comes down as a disk img file, which I can not mount in loopback. Probably encrypted, and knowing them in AES256.

Anyone built a remote NAS box?  How to share those drives with minimal software intervention?



--- On Mon, 10/5/09, adfas asd <chimera_god@yahoo.com> wrote:

> From: adfas asd <chimera_god@yahoo.com>
> Subject: NAS Remote Side of a Mirror
> To: linux-raid@vger.kernel.org
> Date: Monday, October 5, 2009, 8:37 AM
> I'm looking at setting up my RAID
> mirrored array so that one side of the mirror is in the HTPC
> and the other is NASsed in the garage, in case of theft or
> fire.
> 
> I am concerned about the boot process though, as the NASsed
> side will not be available until the network comes up. 
> Will the array be able to be patient for that and include
> that side once it comes up, and run not degraded?
> 
> What if I lose my local side of the mirror?  Is
> failover possible to the NAS side?  (Assuming a
> separate boot disk with everything except /home, which is on
> the array)
> 
> The only other technology I am aware of which can remote
> drives at distance is fibrechannel, and that's too
> expensive, so it seems I'm stuck with GB ethernet.  Are
> there in fact any other options?
> 
> Is it possible to bring up ethernet early in the boot
> process with initrd.img?
> 
> Has anyone actually done any of this?
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

RE: NAS Remote Side of a Mirror

[Chris Green]

Why do you think samba would be a bad choice? I did a quick search for qnap benchmarks, and the numbers didn't look
like anything special compared to my "generic pc + linux + software raid + samba + gbE" setup.


-----Original Message-----
From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of adfas asd
Sent: Wednesday, October 07, 2009 4:49 PM
To: linux-raid@vger.kernel.org
Subject: Re: NAS Remote Side of a Mirror

OK, say I wanted to build this remote NAS box myself, rather than spending $750 for a Qnap. (http://qnap.com/pro_detail_feature.asp?p_id=110)  I find a good case, power supply, micro mobo, and cage, and install Linux and NX (remote desktop) on it.
 
I need to share those drives over GbE with minimal software intervention. I'm not about to use bloatware like NFS or Samba. And sshfs or an SSH tunnel could not keep up the speeds I'd need. How do you suppose Qnap shares those drives? And provides all those other services?
 
So looking at Qnap's update, it comes down as a disk img file, which I can not mount in loopback. Probably encrypted, and knowing them in AES256.

Anyone built a remote NAS box?  How to share those drives with minimal software intervention?



--- On Mon, 10/5/09, adfas asd <chimera_god@yahoo.com> wrote:

> From: adfas asd <chimera_god@yahoo.com>
> Subject: NAS Remote Side of a Mirror
> To: linux-raid@vger.kernel.org
> Date: Monday, October 5, 2009, 8:37 AM
> I'm looking at setting up my RAID
> mirrored array so that one side of the mirror is in the HTPC
> and the other is NASsed in the garage, in case of theft or
> fire.
> 
> I am concerned about the boot process though, as the NASsed
> side will not be available until the network comes up. 
> Will the array be able to be patient for that and include
> that side once it comes up, and run not degraded?
> 
> What if I lose my local side of the mirror?  Is
> failover possible to the NAS side?  (Assuming a
> separate boot disk with everything except /home, which is on
> the array)
> 
> The only other technology I am aware of which can remote
> drives at distance is fibrechannel, and that's too
> expensive, so it seems I'm stuck with GB ethernet.  Are
> there in fact any other options?
> 
> Is it possible to bring up ethernet early in the boot
> process with initrd.img?
> 
> Has anyone actually done any of this?
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAS Remote Side of a Mirror

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Wed Oct 07, 2009 at 04:49:09PM -0700, adfas asd wrote:

> OK, say I wanted to build this remote NAS box myself, rather than
> spending $750 for a Qnap.
> (http://qnap.com/pro_detail_feature.asp?p_id=110)  I find a good case,
> power supply, micro mobo, and cage, and install Linux and NX (remote
> desktop) on it.
>  
> I need to share those drives over GbE with minimal software
> intervention. I'm not about to use bloatware like NFS or Samba. And
> sshfs or an SSH tunnel could not keep up the speeds I'd need. How do
> you suppose Qnap shares those drives? And provides all those other
> services?
>  
> So looking at Qnap's update, it comes down as a disk img file, which I
> can not mount in loopback. Probably encrypted, and knowing them in
> AES256.
> 
> Anyone built a remote NAS box?  How to share those drives with minimal
> software intervention?
> 
The lowest level approach would probably be to export it as iSCSI - I
don't know what overhead the software initiator has for that (or what a
hardware initiator would cost) though.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: NAS Remote Side of a Mirror

[adfas asd]

--- On Wed, 10/7/09, Chris Green <cgreen@valvesoftware.com> wrote:
> Why do you think samba would be a bad
> choice? I did a quick search for qnap benchmarks, and the
> numbers didn't look
> like anything special compared to my "generic pc + linux +
> software raid + samba + gbE" setup.

Samba was great, and I used it through the 20th century, but compared with FUSE it sucks in so many ways, as does NFS


--- On Thu, 10/8/09, Robin Hill <robin@robinhill.me.uk> wrote:
> The lowest level approach would probably be to export it as
> iSCSI - I
> don't know what overhead the software initiator has for
> that (or what a
> hardware initiator would cost) though.

Interesting.  No idea what iSCSI is, but I'll research it.






      

Re: NAS Remote Side of a Mirror

[John Robinson]

On 08/10/2009 12:39, adfas asd wrote:
> --- On Wed, 10/7/09, Chris Green <cgreen@valvesoftware.com> wrote:
>> Why do you think samba would be a bad
>> choice? I did a quick search for qnap benchmarks, and the
>> numbers didn't look
>> like anything special compared to my "generic pc + linux +
>> software raid + samba + gbE" setup.
> 
> Samba was great, and I used it through the 20th century, but compared with FUSE it sucks in so many ways, as does NFS

Hang on - you still need Samba to export a Linux filesystem to Windows 
clients, don't you? And that's what a NAS has to do.

Cheers,

John.

Re: NAS Remote Side of a Mirror

[adfas asd]

--- On Thu, 10/8/09, John Robinson <john.robinson@anonymous.org.uk> wrote:
> Hang on - you still need Samba to export a Linux filesystem
> to Windows clients, don't you? And that's what a NAS has to
> do.

Winduhs clients?  We don't need no steenkin' Winduhs clients...




      

Re: NAS Remote Side of a Mirror

[adfas asd]

> > Hang on - you still need Samba to export a Linux
> filesystem
> > to Windows clients, don't you? And that's what a NAS
> has to
> > do.
> 
> Winduhs clients?  We don't need no steenkin' Winduhs
> clients...

But if you are forced to deal with inferior software, the FUSE project (http://sourceforge.net/apps/mediawiki/fuse/index.php) has all kinds of solutions, like http://sourceforge.net/apps/mediawiki/fuse/index.php?title=NetworkFileSystems#SMBNetFS


      

Re: NAS Remote Side of a Mirror

[John Robinson]

On 08/10/2009 13:15, adfas asd wrote:
> --- On Thu, 10/8/09, John Robinson <john.robinson@anonymous.org.uk> wrote:
>> Hang on - you still need Samba to export a Linux filesystem
>> to Windows clients, don't you? And that's what a NAS has to
>> do.
> 
> Winduhs clients?  We don't need no steenkin' Winduhs clients...

In which case no, you don't need Samba, you never did need Samba and 
I've no idea why you were using it.

The QNAP NAS you linked to does export filesystems via SMB using Samba, 
as well as via AFS, NFS, FTP and HTTP. It can also export volumes via 
iSCSI. It almost certainly runs LVM over md RAID to do all these things.

If you want to build a box to put in your garage which exports raw discs 
over ethernet, you might want to consider nbd (Network Block Device) or 
similar, or iSCSI. If you want it to export files, you will need to run 
a filesystem and expose them using Samba, AFS or NFS, depending on your 
client and preference.

I have a box in my hall cupboard which has 3 1TB discs. They're 
partitioned into two partitions each. The first partitions make up md0 
with RAID-1 which mounts as /boot in the Xen dom0. The second partitions 
make up md1 with RAID-5 with a write-intent bitmap, over which I run 
LVM, which has logical volumes for the Xen dom0 root filesystem, various 
other Xen guests' filesystems, and a large filestore. The filestore 
volume is formatted ext3 and exported to the network with Samba to 
Windows clients and NFS to Linux clients. Fast clients also using 
gigabit ethernet manage ~80MB/s reading and ~60MB/s writing large files 
over either SMB or NFS. The machine also runs a MythTV backend. I have 
done some performance tuning to get where I am, some of it discussed on 
this list, and now I have no performance problems, and just look at all 
those layers...

Cheers,

John.

Re: NAS Remote Side of a Mirror

[russ]

Have you guys looked at nexentastor?  They have a 2TB developer edition and support a host of protocols with pretty decent speeds.  

They use a solaris kernel, so you'd need hardware that supports that.

Russ
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Robin Hill <robin@robinhill.me.uk>
Date:	Thu, 8 Oct 2009 08:51:07 
To: <linux-raid@vger.kernel.org>
Subject: Re: NAS Remote Side of a Mirror

On Wed Oct 07, 2009 at 04:49:09PM -0700, adfas asd wrote:

> OK, say I wanted to build this remote NAS box myself, rather than
> spending $750 for a Qnap.
> (http://qnap.com/pro_detail_feature.asp?p_id=110)  I find a good case,
> power supply, micro mobo, and cage, and install Linux and NX (remote
> desktop) on it.
>  
> I need to share those drives over GbE with minimal software
> intervention. I'm not about to use bloatware like NFS or Samba. And
> sshfs or an SSH tunnel could not keep up the speeds I'd need. How do
> you suppose Qnap shares those drives? And provides all those other
> services?
>  
> So looking at Qnap's update, it comes down as a disk img file, which I
> can not mount in loopback. Probably encrypted, and knowing them in
> AES256.
> 
> Anyone built a remote NAS box?  How to share those drives with minimal
> software intervention?
> 
The lowest level approach would probably be to export it as iSCSI - I
don't know what overhead the software initiator has for that (or what a
hardware initiator would cost) though.

Cheers,
    Robin
-- 
___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

Re: NAS Remote Side of a Mirror

[adfas asd]

--- On Thu, 10/8/09, John Robinson <john.robinson@anonymous.org.uk> wrote:
> In which case no, you don't need Samba, you never did need
> Samba and I've no idea why you were using it.

I used Samba because it was the only alternative to that NFS bloatware in the Olden Days.  Then I graduated into the 21st century and have used FUSE (sshfs) ever since.


--- On Thu, 10/8/09, John Robinson <john.robinson@anonymous.org.uk> wrote:
> The QNAP NAS you linked to does export filesystems via SMB
> using Samba, as well as via AFS, NFS, FTP and HTTP. It can
> also export volumes via iSCSI. It almost certainly runs LVM
> over md RAID to do all these things.

It's looking like iSCSI is the ticket as it can write directly to SCSI buffers using iSER. (http://en.wikipedia.org/wiki/ISCSI_Extensions_for_RDMA) No hardware needed, just some kernel modules.  This, barring some find in FUSE Networked Filesystems. (http://sourceforge.net/apps/mediawiki/fuse/index.php?title=NetworkFileSystems)

FUSE is amazing.  Just look at these encrypted filesystem options:
 http://sourceforge.net/apps/mediawiki/fuse/index.php?title=EncryptedFileSystems
... Needless to say, these may be too slow for RAIDing, but it just shows the depth of FUSE.

But I can not understand where LVM would come into play with the Qnap?  Why?

 



      

Re: NAS Remote Side of a Mirror

[adfas asd]

--- On Thu, 10/8/09, russ@vshift.com <russ@vshift.com> wrote:
> Have you guys looked at
> nexentastor?  They have a 2TB developer edition and
> support a host of protocols with pretty decent speeds. 

Thanks, but I already have more than 2TB, and any more costs.  And although I like ZFS, it's not worth a whole 'nother OS for it.  Sticking with Debian until I get sick of all the bugs lately...


      

RE: NAS Remote Side of a Mirror

[Leslie Rhorer]

> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of adfas asd
> Sent: Wednesday, October 07, 2009 6:49 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: NAS Remote Side of a Mirror
> 
> OK, say I wanted to build this remote NAS box myself, rather than spending
> $750 for a Qnap. (http://qnap.com/pro_detail_feature.asp?p_id=110)  I find
> a good case, power supply, micro mobo, and cage, and install Linux and NX
> (remote desktop) on it.

	I'm not familiar with NX.  Why not X11?

> I need to share those drives over GbE with minimal software intervention.
> I'm not about to use bloatware like NFS or Samba. And sshfs or an SSH
> tunnel could not keep up the speeds I'd need. How do you suppose Qnap

	Why do you say that?  From what I have seen of your requirements, it
doesn't sound like you will require very much at all in the way of speed on
your array.

	Speaking of which, I never did see where you posted the results of
any drive access metrics.

RE: NAS Remote Side of a Mirror

[adfas asd]

--- On Sat, 10/10/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>     I'm not familiar with NX.  Why not
> X11?

I tried to set up remote X a long time ago, but it was just too problematic.  NX does essentially the same thing, and has built-in security. (nomachine.com)  Works great, and is very fast.
 

> > I'm not about to use bloatware like NFS or Samba. And
> sshfs or an SSH
> > tunnel could not keep up the speeds I'd need. How do
> you suppose Qnap
> 
>     Why do you say that?  From what I
> have seen of your requirements, it
> doesn't sound like you will require very much at all in the
> way of speed on
> your array.

Why do I say that?  Because they -are- bloatware, and an unnecessary fat layer in the system, with all the potential for error and security breach that implies.  iSCSI is the way, in the 21st century.
 

>     Speaking of which, I never did see where
> you posted the results of
> any drive access metrics.

I'm sure I mentioned these are the WD 2TB drives.  Straight read 77.7MB/s in RAID10offset.




      

Re: NAS Remote Side of a Mirror

[Drew]

> Why do I say that?  Because they -are- bloatware, and an unnecessary fat layer in the system, with all the potential for error and security breach that implies.  iSCSI is the way, in the 21st century.

Actually, iSCSI is far from secure. Google "iscsi security" and the
first link that comes up is a pdf from a recent BlackHat convention.
Give that a good read before you claim NFS & samba are bigger security
risks then iSCSI.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAS Remote Side of a Mirror

[adfas asd]

Thanks for the reference.

Of course I'll use iptables to ensure a connection only from the remote SAN to the HTPC.  I'd set up a tunnel, but that's likely to impact performance too much, especially with a 1.2GHz Atom.


--- On Sat, 10/10/09, Drew <drew.kay@gmail.com> wrote:

> From: Drew <drew.kay@gmail.com>
> Subject: Re: NAS Remote Side of a Mirror
> To: "adfas asd" <chimera_god@yahoo.com>
> Cc: linux-raid@vger.kernel.org
> Date: Saturday, October 10, 2009, 7:21 AM
> > Why do I say that?  Because
> they -are- bloatware, and an unnecessary fat layer in the
> system, with all the potential for error and security breach
> that implies.  iSCSI is the way, in the 21st century.
> 
> Actually, iSCSI is far from secure. Google "iscsi security"
> and the
> first link that comes up is a pdf from a recent BlackHat
> convention.
> Give that a good read before you claim NFS & samba are
> bigger security
> risks then iSCSI.
> 
> 
> -- 
> Drew
> 
> "Nothing in life is to be feared. It is only to be
> understood."
> --Marie Curie
> 


      

Re: NAS Remote Side of a Mirror

[Thomas Fjellstrom]

On Sat October 10 2009, adfas asd wrote:
> --- On Sat, 10/10/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> >     I'm not familiar with NX.  Why not
> > X11?
> 
> I tried to set up remote X a long time ago, but it was just too
>  problematic.  NX does essentially the same thing, and has built-in
>  security. (nomachine.com)  Works great, and is very fast.
> 
> > > I'm not about to use bloatware like NFS or Samba. And
> >
> > sshfs or an SSH
> >
> > > tunnel could not keep up the speeds I'd need. How do
> >
> > you suppose Qnap
> >
> >     Why do you say that?  From what I
> > have seen of your requirements, it
> > doesn't sound like you will require very much at all in the
> > way of speed on
> > your array.
> 
> Why do I say that?  Because they -are- bloatware, and an unnecessary fat
>  layer in the system, with all the potential for error and security breach
>  that implies.  iSCSI is the way, in the 21st century.

iSCSI is also bloatware you know. If you want something thin and light, try 
ATA Over Ethernet (AoE), or DRBD, or NBD.

> >     Speaking of which, I never did see where
> > you posted the results of
> > any drive access metrics.
> 
> I'm sure I mentioned these are the WD 2TB drives.  Straight read 77.7MB/s
>  in RAID10offset.
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: NAS Remote Side of a Mirror

[adfas asd]

--- On Sat, 10/10/09, Thomas Fjellstrom <tfjellstrom@shaw.ca> wrote:
> iSCSI is also bloatware you know. If you want something
> thin and light, try 
> ATA Over Ethernet (AoE), or DRBD, or NBD.

Apparently not.  As I say, MySQL performance tests show iSCSI is actually faster than DAS SCSI.


      

RE: NAS Remote Side of a Mirror

[Leslie Rhorer]

> --- On Sat, 10/10/09, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> >     I'm not familiar with NX.  Why not
> > X11?
> 
> I tried to set up remote X a long time ago, but it was just too
> problematic.  NX does essentially the same thing, and has built-in
> security. (nomachine.com)  Works great, and is very fast.

	X11 is not overly slow, and I have never had any really significant
problems with it.  I've been using it on a large number of systems across
several platforms for over 15 years.  Of course, no system is completely
free of issues, but X11 on *nix platforms has presented me with very few.

	I'm relatively new to Linux, but I've had few problems setting up
X11 on any Linux platform, and none at all once I have it set up.  I'm
running X11 on several Debian platforms here in my house.  For X-server
access via Windows workstations, I use X-Ming.  For access via one of the
Linux servers, I just ssh to the remote and start whatever X-Client I want.
KDM (which I like) also allows simple XDMCP support, although I never use
it.

> > > I'm not about to use bloatware like NFS or Samba. And
> > sshfs or an SSH
> > > tunnel could not keep up the speeds I'd need. How do
> > you suppose Qnap
> >
> >     Why do you say that?  From what I
> > have seen of your requirements, it
> > doesn't sound like you will require very much at all in the
> > way of speed on
> > your array.
> 
> Why do I say that?  Because they -are- bloatware, and an unnecessary fat
> layer in the system, with all the potential for error and security breach
> that implies.  iSCSI is the way, in the 21st century.

	That's not what I asked.  Why do you say (or think) you will need
much in the way of speed?  I didn't ask you anything about SAMBA or NFS.  I
use both, as it happens, on several of my servers, but I don't use either to
backup the Video Server.  I do have a NFS export from my Backup Server to
the Video Server just for convenience.  I certainly agree iSCSI is a good
choice for creating remote member disks on a RAID array.  Indeed it is
probably what I would use if I were creating an array with remote members,
but I am unconvinced this will be the best solution for you given what you
have told us about your requirements.  Of course, you know your requirements
better than we.

> >     Speaking of which, I never did see where
> > you posted the results of
> > any drive access metrics.
> 
> I'm sure I mentioned these are the WD 2TB drives.  Straight read 77.7MB/s
> in RAID10offset.

	Again, that's not what I asked.  I didn't ask you for drive
specifications or benchmark performance.  I asked you for drive access
metrics.  Under heavy load conditions with your software mix, how much read
and write bandwidth is being used, particularly once you separate off the
SQL database on a separate drive system from the main array?

	BTW, while a straight read of ~80 Mbps is not blazingly fast, it's
vastly more than you need strictly for video streams.  Real-time 1080i video
is generally less than 2 MB/s.  A read rate of more than 70 MB/s can easily
handle more than 20 HD streams in real time, and I doubt you are going to
handle more than 20 simultaneous streams.  Commercial tagging can of course
eat up considerably more bandwidth than real-time streams, but you are
complaining of response problems when doing commercial tagging, which would
rather suggest you aren't stressing the drive subsystems.  The only way to
know for certain, however is to actually measure the drive load when the
application is running.  For example, while on straight reads I can
sometimes peak above 100 MB/s with continuous rates above 90 MB/s, this is
what I see during a commercial scan:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.43    0.00    8.74    0.49    0.00   88.35

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda               9.00         1.42         0.34          1          0
sdb              11.00         1.52         0.26          1          0
sdc              11.00         1.27         0.42          1          0
sdd              10.00         1.27         0.50          1          0
sde              11.00         1.52         0.50          1          0
sdf              11.00         1.52         0.50          1          0
sdg              12.00         1.27         0.76          1          0
sdh              10.00         1.25         0.76          1          0
sdi              10.00         1.26         0.76          1          0
sdj              10.00         1.26         0.76          1          0
hda               5.00         0.00         0.09          0          0
hda1              0.00         0.00         0.00          0          0
hda2              3.00         0.00         0.08          0          0
hda3              0.00         0.00         0.00          0          0
hda4              2.00         0.00         0.01          0          0
hda5              0.00         0.00         0.00          0          0
md0             198.00        12.00         4.02         12          4

	There was also a 30 Mbps ftp session writing to disk from a TiVo,
which is why you see the non-zero write metrics.  That's a far cry from more
than 70 MB/s, is the point, though.  Compare that with an rsync over ssh to
the remote backup system:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          27.76    0.00   15.97    0.00    0.00   56.27

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda              10.00         4.00         0.00          8          0
sdb              10.00         4.00         0.00          8          0
sdc              10.00         4.00         0.00          8          0
sdd              10.00         4.00         0.00          8          0
sde              10.00         4.00         0.00          8          0
sdf              10.00         4.00         0.00          8          0
sdg              10.00         4.00         0.00          8          0
sdh              10.00         4.00         0.00          8          0
sdi              10.00         4.00         0.00          8          0
sdj              10.00         4.00         0.00          8          0
hda               1.50         0.00         0.04          0          0
hda1              0.00         0.00         0.00          0          0
hda2              1.50         0.00         0.04          0          0
hda3              0.00         0.00         0.00          0          0
hda4              0.00         0.00         0.00          0          0
hda5              0.00         0.00         0.00          0          0
md0             504.00        42.00         0.00         84          0

	That's 350% greater bandwidth being gulped down, and that with a
write going on at the far end.  If I do a cmp between a local file and the
same file on the backup server over NFS, I get:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.67    0.00   21.38   27.03    0.00   46.93

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda              17.00         6.13         0.13         12          0
sdb              17.50         6.13         0.13         12          0
sdc              17.00         6.13         0.13         12          0
sdd              17.00         6.00         0.25         12          0
sde              16.50         5.75         0.25         11          0
sdf              16.00         5.75         0.25         11          0
sdg              17.50         6.10         0.16         12          0
sdh              17.00         6.13         0.13         12          0
sdi              17.00         6.13         0.13         12          0
sdj              17.00         6.13         0.13         12          0
hda               2.00         0.00         0.05          0          0
hda1              0.00         0.00         0.00          0          0
hda2              1.50         0.00         0.05          0          0
hda3              0.00         0.00         0.00          0          0
hda4              0.50         0.00         0.00          0          0
hda5              0.00         0.00         0.00          0          0
md0             720.00        60.00         0.00        120          0

	Drives sda - sdj are all members of md0.