Trouble with ZFS mounts
in [Solaris]
|
Prev: mysterious 15-minute delay at boot in Ultra 20 running Solaris 10 X86
Next: mysterious 15-minute delay at boot in Ultra 20 running Solaris10 X86
From: Ian Collins on 8 Aug 2010 17:19 Please keep context! On 08/ 9/10 09:08 AM, Paul Branon wrote: > Hi Ian, > > Yes, it's a really difficult problem to spot. But, put simply, both > the global zone and the local zone have various partitions which act > as mountpoints for the zfs filesystems and they are > > (a) > rpool/home mounted on /home > rpool/opt mounted on /opt > rpool/output1 mounted on /output01 > etc, etc,etc > you see them all if you look at the output here: > http://www.wuppdich.com/combined_error.txt Posting links to Usenet is a bad idea, that may not be there when someone reads the thread, keep the information here. Your zone config was: set zonepath=/zoneroot/localzone01 set autoboot=false add net set address=${mainip}/16 set physical=${interfaceprefix}0 end add net set address=${secondip}/$secondnetmask ${routerstring} set physical=${secondinterface} end add dataset set name=rpool/zonedata/localzone01 end add fs set dir=/output01 set special=/output01/zone set type=lofs set options=[rw] end So there aren't any filesystems mounted at /home or /opt in the zone. > (b) > But, the local zone is behaving badly and not mounting its /opt or / > output01 > filesystems properly. (And I think I know why. I think it's because it > has not been > configured to mount rpool/opt on /opt or rpool/output01 on /output01 > (ie the guy who wrote the scripts forgot that bit, and has been doing > that bit by > hand, I guess.) But the scripts were passed to me and I'd never run > them before > and someone said "hey. those new local zones don't mount /opt or / > output01 > as separate partitions they just write that data straight to / > (which since on the globalzone is zonepath /zoneroot/localzone01/root/ > will amount to /zoneroot/localzone01/root/output01 and > /zoneroot/localzone01/root/opt respectively. As I said in my reply you snipped, you have to add looback mounts to the zone's config. -- Ian Collins
From: Paul Branon on 8 Aug 2010 17:30 On Aug 8, 10:19 pm, Ian Collins <ian-n...(a)hotmail.com> wrote: > Please keep context! > > On 08/ 9/10 09:08 AM, Paul Branon wrote: > > > Hi Ian, > > > Yes, it's a really difficult problem to spot. But, put simply, both > > the global zone and the local zone have various partitions which act > > as mountpoints for the zfs filesystems and they are > > > (a) > > rpool/home mounted on /home > > rpool/opt mounted on /opt > > rpool/output1 mounted on /output01 > > etc, etc,etc > > you see them all if you look at the output here: > >http://www.wuppdich.com/combined_error.txt > > Posting links to Usenet is a bad idea, that may not be there when > someone reads the thread, keep the information here. > > Your zone config was: > > set zonepath=/zoneroot/localzone01 > set autoboot=false > add net > set address=${mainip}/16 > set physical=${interfaceprefix}0 > end > add net > set address=${secondip}/$secondnetmask > ${routerstring} > set physical=${secondinterface} > end > add dataset > set name=rpool/zonedata/localzone01 > end > add fs > set dir=/output01 > set special=/output01/zone > set type=lofs > set options=[rw] > end > > So there aren't any filesystems mounted at /home or /opt in the zone. > > > > > (b) > > But, the local zone is behaving badly and not mounting its /opt or / > > output01 > > filesystems properly. (And I think I know why. I think it's because it > > has not been > > configured to mount rpool/opt on /opt or rpool/output01 on /output01 > > (ie the guy who wrote the scripts forgot that bit, and has been doing > > that bit by > > hand, I guess.) But the scripts were passed to me and I'd never run > > them before > > and someone said "hey. those new local zones don't mount /opt or / > > output01 > > as separate partitions they just write that data straight to / > > (which since on the globalzone is zonepath /zoneroot/localzone01/root/ > > will amount to /zoneroot/localzone01/root/output01 and > > /zoneroot/localzone01/root/opt respectively. > > As I said in my reply you snipped, you have to add looback mounts to the > zone's config. > > -- > Ian Collins Yes, Ian, thanks. /home is not one of the file systems that concerns us, but /output01 definitely is and so too is /opt and yes. I completely agree with you those mountpoints are missing in the script. (and I think the guy has been traditionally adding the mountpoints by hand.) I completely agree. However, the slightly more challenging issue is one of retrieving any wrongly written data. Because the local zones went into production with the wrong mountpoints, (clearly.) But I'm wondering if that's really a genuine problem at all, because we all know where the data is. It's in the global zone under /zoneroot/localzone01/root/opt and the same path ending in output01. So, maybe all that needs doing is adding the loopback mounts to the localzone and restarting it. Maybe no data needs to get physically moved at all. That's the issue I'm having. Regards and many, many thanks for the sanity checking. It's mucho, mucho appreciated. Paulb.
From: Ian Collins on 8 Aug 2010 17:54 On 08/ 9/10 09:30 AM, Paul Branon wrote: > On Aug 8, 10:19 pm, Ian Collins<ian-n...(a)hotmail.com> wrote: >> >> As I said in my reply you snipped, you have to add looback mounts to the >> zone's config. > > Yes, Ian, thanks. /home is not one of the file systems that concerns > us, but /output01 definitely is and so too is /opt and yes. I > completely agree with you those mountpoints are missing in the script. > (and I think the guy has been traditionally adding the mountpoints by > hand.) I completely agree. > > However, the slightly more challenging issue is one of retrieving any > wrongly written data. Because the local zones went into production > with the wrong mountpoints, (clearly.) But I'm wondering if that's > really a genuine problem at all, because we all know where the data > is. It's in the global zone under /zoneroot/localzone01/root/opt and > the same path ending in output01. Which is probably fine. Adding mountpoints for the sake of adding them is seldom a good idea. The main reason to add a loop-back mount is to share data managed from the global zone to a non-global zone. I have never attempted to loop-back mount read write. > So, maybe all that needs doing is adding the loopback mounts to the > localzone and restarting it. Maybe no data needs to get physically > moved at all. > > That's the issue I'm having. I wouldn't bother. You know where that data is (and it's where most people would expect it to be). Unless you have a compelling reason for complicating things' don't bother! -- Ian Collins
From: Paul Branon on 8 Aug 2010 18:03
On Aug 8, 10:54 pm, Ian Collins <ian-n...(a)hotmail.com> wrote: > On 08/ 9/10 09:30 AM, Paul Branon wrote: > > > > > On Aug 8, 10:19 pm, Ian Collins<ian-n...(a)hotmail.com> wrote: > > >> As I said in my reply you snipped, you have to add looback mounts to the > >> zone's config. > > > Yes, Ian, thanks. /home is not one of the file systems that concerns > > us, but /output01 definitely is and so too is /opt and yes. I > > completely agree with you those mountpoints are missing in the script. > > (and I think the guy has been traditionally adding the mountpoints by > > hand.) I completely agree. > > > However, the slightly more challenging issue is one of retrieving any > > wrongly written data. Because the local zones went into production > > with the wrong mountpoints, (clearly.) But I'm wondering if that's > > really a genuine problem at all, because we all know where the data > > is. It's in the global zone under /zoneroot/localzone01/root/opt and > > the same path ending in output01. > > Which is probably fine. Adding mountpoints for the sake of adding them > is seldom a good idea. The main reason to add a loop-back mount is to > share data managed from the global zone to a non-global zone. I have > never attempted to loop-back mount read write. > > > So, maybe all that needs doing is adding the loopback mounts to the > > localzone and restarting it. Maybe no data needs to get physically > > moved at all. > > > That's the issue I'm having. > > I wouldn't bother. You know where that data is (and it's where most > people would expect it to be). Unless you have a compelling reason for > complicating things' don't bother! > > -- > Ian Collins The compelling reason is the client said that his data was in the wrong place because the localzone's mountpoints are not correct. And he has been using these scripts for two years and I've only used them once! That's why I don't know how he normally overcomes the omissions in the scripts, because I've never seen him do it. But part of my brief is to recover the wrongly written data and put it where it ought to have been written. But looking at the config tells us where the data is. It doesn't seem wrongly written at all. Wrongly mounted, yes. Guilty as charged. But wrongly written? (I suspect not.) But I needed to check. And that's what I'm doing. Many thanks. I think I'm done now! Paulb |