> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx
> [mailto:centos-bounces@xxxxxxxxxx] On Behalf Of Andrew Cotter
> Sent: Friday, February 23, 2007 10:59 AM
> To: CentOS mailing list
> Subject: RE: iSCSI, windows, & local linux access
>
> > Yes, it will be an NTFS partition, but with the "plus"
> kernel you can
> > use the read-only ntfs module to read the data on the Linux
> side, just
> > take an LVM snapshot, use the loopback with the sector offset of the
> > partition in the snapshot lv to mount it locally. Remove
> the snapshot
> > when done.
>
> Does the snapshot take utilize the same amount of space? If
> I have 3TB of
> files, do a snapshot, do I then have 6TB of data on disk?
No, the snapshot just stores the changes from the original volume for
the duration of the snapshot from the point-in-time of when the snapshot
is taken.
> A little more background....
>
> Why we are doing this is we are (re)building our array to store our
> disk-disk backups using BackupExec. The older versions did
> no mind using a
> smb share but since we have updated to 10d it will not connect and
> Symantec/Veritas does not support this. That is why we
> thought iSCSI would
> do the trick.
Hmmm, backups use large block io, I would definitely look at using the
latest SVN of iscsitarget and using the block-io module, not just
because I helped develop it, but because it performs large block io a
lot faster than the file-io module.
> > You can't rsync NTFS partitions, but you could use drbd and
> scheduled
> > replication to block-level replicate it. Use drbd without heartbeat,
> > have it sync up asynchronously using Prot A, once it is
> sync'd have it
> > disconnect and run standalone with secondary in
> wait-for-connect, using
> > 'cron' bring up the connection again, when it is sync'd
> bring it down
> > again.
>
> Where rysnc came in for us was we then take some of those
> backups and spool
> them off over a VPN to a remote site. In addition, we would
> take a SATA
> drive, mount it, copy some data, pull it, then take it
> offsite like people
> traditionally do with tape. I have read a bit about drdb and
> that might
> work. We would have to be selective somehow since we have a
> smaller array
> at the other end meant to only hold 2wks of backups.
If you take your 6TB volume and split it into LVs for each job type, you
can selectively replicate LVs between storage units. Don't allocate all
your 6TB right away, just allocate what you need for each job type now,
then you can always grow a LV as the job grows. Simple take the iSCSI
volume offline, lvresize it, bring it back online, use Windows volume
resize (in 2003 I believe) and then you have a larger volume.
If LV contiguous space is a concern, which it should with such a large
volume, start by breaking it into large regions, say 4 by creating 4
large LVs, then resize them down to what you need which will leave
contiguous gaps in between for growth or other needs, once they are
resized down then export them via iSCSI and create your Windows
partition. Playing around with this concept will allow you to properly
utilize the storage surface. The original IBM LVM had the concept of
drive region allocation where you could have a LV allocate extends from
the beginning (fastest), the middle (avg) and the end (slowest) of the
vg, by using these regions (3) and some trickery you can accomplish the
same type of affect.
> We used to do this with a 1TB array and smb but our data has
> grown fairly
> rapidly.
It always does.
> Would something like NFS possibly suit us better?
Not with Backup Exec being your application. No, iSCSI will definitely
work a lot better for this application than NFS or CIFS.
> Thanks for the suggestions!
>
> Andrew
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
