From: Jerry N. <jn...@br...> - 2004-07-30 16:57:03
Attachments:
Jerry Norton (jnorton@broadgap.com).vcf
|
Hey all, I have a strange question/scenario that I'm not sure is even possible. Is it possible to have the data directory point to a windows server mount point? What about rights/permissions? I'm using the Debian package right now, so how would I create the link to move the data store? The reason I ask is because I have a windows server with a fiber channel array and shloads of free space. Moving the array to linux is not an option as it is already a backup store for our windows backup solution. I would really like to keep all my backup stores in one place because of fault tolerance and because of the available HD space. Has anyone tried this? Any ideas/suggestions would be greatly appreciated. Thanks in advance, Jerry Norton broadGap Technologies | www.broadgap.com D (801) 763-8056x21 | F (801) 763-8095 | C (801) 368-6159 |
From: Tony N. <tn...@st...> - 2004-07-30 18:56:03
|
Won't work.. search the lists.. Windows doesn't support hard links which is necessary for the BackupPC pool. -- Tony Nelson Director of IT Operations Starpoint Solutions LLC 115 Broadway, 2nd Fl New York, NY 10006 Quoting Jerry Norton <jn...@br...>: > Hey all, I have a strange question/scenario that I'm not sure is even > possible. > > Is it possible to have the data directory point to a windows server mount > point? > What about rights/permissions? > I'm using the Debian package right now, so how would I create the link to > move the > data store? > > The reason I ask is because I have a windows server with a fiber channel > array and > shloads of free space. Moving the array to linux is not an option as it is > already > a backup store for our windows backup solution. I would really like to keep > all my > backup stores in one place because of fault tolerance and because of the > available > HD space. > > Has anyone tried this? Any ideas/suggestions would be greatly appreciated. > > Thanks in advance, > > Jerry Norton > broadGap Technologies | www.broadgap.com > D (801) 763-8056x21 | F (801) 763-8095 | C (801) 368-6159 > > This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it. |
From: Wayne S. <ws...@bi...> - 2004-07-30 19:07:40
|
From: Tony Nelson <tn...@st...> > Won't work.. search the lists.. Windows doesn't support hard links which is > necessary for the BackupPC pool. Well actually I believe you CAN do hard links on NTFS, but yes it would be hard to port this beast to Windows. -Wayne |
From: Les M. <le...@fu...> - 2004-07-30 19:24:46
|
On Fri, 2004-07-30 at 13:54, Tony Nelson wrote: > Won't work.. search the lists.. Windows doesn't support hard links which is > necessary for the BackupPC pool. NTFS actually does support hard links - windows just lacks a command to create them and smbmount may not pass them through in any case. There would be some chance of getting it to work if you can install windows "services for unix" which is currently a free download and NFS export the directory to use for storage. I haven't tried this but it would be pretty lame if they didn't handle hard links through the NFS server. If that fails you might create a huge file in a directory accessed via smbmount, then make an ext3 or reiser filesystem on it and mount it via the loopback interface (-o loop). I'd test pretty carefully to be sure you don't hit any lingering 2Gb size limits in smbmount, though. --- Les Mikesell le...@fu... |
From: Guus H. <gu...@ho...> - 2004-08-02 08:15:14
|
Hi, Les Mikesell wrote: > On Fri, 2004-07-30 at 13:54, Tony Nelson wrote: > >>Won't work.. search the lists.. Windows doesn't support hard links which is >>necessary for the BackupPC pool. > > > NTFS actually does support hard links - windows just lacks a command to > create them and smbmount may not pass them through in any case. There > would be some chance of getting it to work if you can install > windows "services for unix" which is currently a free download and > NFS export the directory to use for storage. I haven't tried this > but it would be pretty lame if they didn't handle hard links through > the NFS server. Well, I tried the NFS client from Services for Unix a few months ago and I wasn't happy with it to say the least. I have a very small NFS setup at home. My linux firewall (the nfs server, v3) has some diskspace I use on my linux/windows workstation. When I run linux on my workstation (99% of the time), nfs works without a flaw. Throughput is ok, no hiccups, just works. When I boot into windows en and use the nfs client from SFU, mounting the exported directory works ok, but transferring files behaves very weird. Sometimes it works ok for a few minutes, then it just stalles, nothing happens and after a few minutes trabsfer starts again and it works again ok for a few minutes, then stalles again and so on and so on. For instance burning a cd from content on the nfs server just isn't possible in windows, but works flawlessly if I boot my workstation in linux. I was very disappointed with it. I tried udp mounting instead of tcp and other options of the nfs client, made no difference. Maybe I'm doing something wrong, but the whole feel of the nfs client from SFU was to me something like emergency use only. Regards, -- Guus Houtzager Email: gu...@ho... PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D "A)bort, R)etry, I)nfluence with large hammer." |
From: Les M. <le...@fu...> - 2004-08-02 12:08:32
|
On Mon, 2004-08-02 at 03:15, Guus Houtzager wrote: > I tried udp mounting instead > of tcp and other options of the nfs client, made no difference. Maybe > I'm doing something wrong, but the whole feel of the nfs client from SFU > was to me something like emergency use only. For BackupPC's use it would be the server performance that matters. I'd expect the biggest difference difference to be in setting a fairly large r/w block size, although years ago I saw problems with some PC network cards dealing with big UDP packets back-to-back. . Also, the blurb for the current 3.5 version of sfu claims much better NFS performance. Were you using that or the earlier one? It generally makes more sense to run samba on Linux than an NFS client on Windows but I thought (and no one has confirmed yet) that the server from sfu might handle hardlinks as needed by backuppc. --- Les Mikesell le...@fu... |
From: Justin G. <jgu...@gm...> - 2004-07-31 02:19:41
|
On Fri, 30 Jul 2004 10:56:31 -0600, Jerry Norton <jn...@br...> wrote: > Hey all, I have a strange question/scenario that I'm not sure is even possible. > > Is it possible to have the data directory point to a windows server mount point? > What about rights/permissions? > I'm using the Debian package right now, so how would I create the link to move the > data store? This would not work purely over SMB since the pooling mechanism uses hardlinks, which are not supported over SMB/NTFS. However I suppose you could mount a disk image file, formatted with ext3 or whatever, through a loopback interface on the SMB share, but I'm guessing this would be too slow. (client->linux box->windows box for every operation, including the hashing and such) -- Justin Guenther IT Analyst CrownAg International Inc. 250 Henderson Drive Regina, SK, Canada S4N 5P7 Tel: (306) 522-8111 Email: jus...@cr... |
From: Guus H. <gu...@ho...> - 2004-08-02 12:19:47
|
Les Mikesell wrote: > On Mon, 2004-08-02 at 03:15, Guus Houtzager wrote: > >> I tried udp mounting instead >>of tcp and other options of the nfs client, made no difference. Maybe >>I'm doing something wrong, but the whole feel of the nfs client from SFU >>was to me something like emergency use only. > > > For BackupPC's use it would be the server performance that > matters. I'd expect the biggest difference difference to > be in setting a fairly large r/w block size, although years > ago I saw problems with some PC network cards dealing with > big UDP packets back-to-back. . Also, the blurb for the > current 3.5 version of sfu claims much better NFS performance. > Were you using that or the earlier one? It generally makes > more sense to run samba on Linux than an NFS client on > Windows but I thought (and no one has confirmed yet) that > the server from sfu might handle hardlinks as needed by > backuppc. Yes, I used the 3.5 version. No idea if that would support hardlinks or not. I wasn't testing this for backuppc purposes :) I don't think it's the nics in my case, because they are the same regardless if I boot in windows or linux :) Maybe the windowsdriver is shabby. I'll probably go the samba route for my home setup. > --- > Les Mikesell > le...@fu... Regards, -- Guus Houtzager Email: gu...@ho... PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D "A)bort, R)etry, I)nfluence with large hammer." |
From: Les M. <le...@fu...> - 2004-08-02 21:31:10
|
On Mon, 2004-08-02 at 07:19, Guus Houtzager wrote: > Yes, I used the 3.5 version. No idea if that would support hardlinks or > not. I wasn't testing this for backuppc purposes :) OK, I downloaded a copy of sfu and a few minutes testing confirms that mounting a windows NFS export onto Linux does support hard links. At least 'ln oldfile newname' works and 'ls -l' shows the link counts go up. The documentation mentioned something about a max of 1024 links that could be changed with an environment setting and another setting that would optimize performance if all access is through NFS instead of having to keep local access in sync. It also has case-sensitivity, so in theory it should work for BackupPC. I don't think I'll try it myself anytime soon, though. I'm having enough trouble fighting a new virus on the windows boxes this week that I don't want to put anything else there. --- Les Mikesell le...@fu... |