[DRBD-user] DRBD w/ HA w/ Large file issue

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Mon Jul 10 16:02:31 CEST 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


pv wrote:
> 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)?
> -- 
> 

drbdadm invalidate resource

on 0.6.x
drbdsetup /dev/nb? replicate
would do the same thing but I was sure that it would only cause the secondary 
to be invalidated... I have not played with 0.7.x enough to know if putting 
one in primary tells it enough to just issue the invalidate on either node and 
thus force the secondary to be invalidated.

> 
> 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.
>> >
>> >
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user


-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter



More information about the drbd-user mailing list