Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thx Todd - you're right - I'd incorrectly created the link for /var/lib/nfs indeed. Any idea(s): on how to trigger a force sync - if for some reason the two disks are known to be not-in-sync? is this something that is not recommended i.e. what if - just to be sure - I set up a script to periodically sync up two disks - if this were possible, would this cause any untoward side-effect(s)? -- On 7/7/06, pv <vishnubhatt at gmail.com> wrote: > > I'm going to ensure that the /var/lib/nfs to make it point to the > /data/nfs (which is exported and laid on top of log vols), I'm testing that > as we speak, Thx for the response. > > Had yet another question - say for some reason you (as a user/admin) > realize that the two disks/devs are not in sync - is there a way to force a > sync from a user-land command? > -- > > > On 7/6/06, Todd Denniston <Todd.Denniston at ssa.crane.navy.mil> wrote: > > > > pv wrote: > > > I have two servers - fedora1, fedora2, wired up w/ drbd and heartbeat > > and I'm > > > exporting the data (residing on the drbd dev) using NFS which is > > visible via > > > the cluster interface (via heartbeat). > > > > > > The export is visible via a cluster interface (e.g. /data/export). I > > mount this > > > export (via the cluster interface) from yet another m/c (nfs client). > > And I'm > > > doing simple pings and copying/touching files - when I turn on/off one > > of the > > > nodes (e.g fedora1), the mount point moves from fedora1 to fedora2 and > > back > > > respectively very well. I copy smaller files and do the same, I do not > > seem to > > > have any problem, but when I try copying a large ISO image file, I see > > the > > > following issue: > > > > > > 1) between the two servers, fedora1 is the primary and I start copying > > the > > > large file. at this time - both servers are up and running and copy > > begins. > > > 2) in between the copy, I turn off fedora1 and observe that fedora2 > > has taken > > > over the cluster interface as well as the nfs export/mount point, but > > I do not > > > see the large file that I started before the failure. > > > > (2) is unexpected by me. > > are you indicating that the file is not visible at the nfs client or > > when > > logged into the server? > > On the server is a big problem. > > At the client is probably some minor misconfiguration of the services on > > the > > server. > > > > > 3) upon failback, I get a stale NFS handle error - in my haresources > > file, I > > > have the following entry: > > > > what does `ls -ld /var/lib/nfs` (pn both machines) return? > > The reason I ask is that the data in /var/lib/nfs needs to be on a disk > > shared > > between the machines and needs to be accessible _before_ starting nfs > > and > > nfslock services. > > > > > > > > > > fedora1 IPaddr::172.30.30.200/24/eth0 drbddisk::r1 > > > Filesystem::/dev/drbd1::/data::ext3 restart-nfs restart-rpcidmapd > > > > > > > do you control any other related services with ha? like the nfs service? > > > > > -- > > > > > > Any idea if my config is wrong or is there an issue dealing w/ large > > files > > > either in drbd or the ha or NFS itself? Thx in advance. > > > > not enough info, but I know I have worked with files bigger than 2GB and > > had > > no problems on drbd 0.6.13 on Fedora Core 1 over NFS managed by > > Heartbeat. > > -- > > Todd Denniston > > Crane Division, Naval Surface Warfare Center (NSWC Crane) > > Harnessing the Power of Technology for the Warfighter > > __ > > please use the "List-Reply" function of your email client. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20060709/de60e9dd/attachment.htm>