> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of Andrew Cotter > Sent: Friday, February 23, 2007 10:59 AM > To: CentOS mailing list > Subject: RE: [CentOS] 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 at centos.org > 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.