Hi All,
Please let me know the procedure how to patch a server which is having 5
zones on zfs file systems.
Root file system exists on internal disk and zones are existed on SAN.
Thank you all,
Bhanu
___
zfs-discuss mailing list
which version of solaris?
s10u? live upgrade, zfs snap, halt zone, backup zone, zoneadm detach zone,
zoneadm attach -U zone after os upgrade by zfs snap and liveupgrade of just
upgrade from dvd
or s11? beadm for new root, upgrade os, treat zone as above
regards
Sent from my iPad
On Jan 21,
Hi
Need more info here, what exactly is the root FS, ie zfs?
what kernel rev is current ( uname -a )
is there a specific patch that is being installed.
if so then Live upgrade is best bet, combined with perhaps recommended
patch cluster.
apply latest rev of 119254 and 121430 ( SPARC ) or (
2012-01-21 0:33, Jim Klimov wrote:
2012-01-13 4:12, Jim Klimov wrote:
As I recently wrote, my data pool has experienced some
unrecoverable errors. It seems that a userdata block
of deduped data got corrupted and no longer matches the
stored checksum. For whatever reason, raidz2 did not
help in
On Sat, 21 Jan 2012, Jim Klimov wrote:
5) It seems like a worthy RFE to include a pool-wide option to
verify-after-write/commit - to test that recent TXG sync
data has indeed made it to disk on (consumer-grade) hardware
into the designated sector numbers. Perhaps the test should
be
2012-01-21 19:18, Bob Friesenhahn wrote:
On Sat, 21 Jan 2012, Jim Klimov wrote:
5) It seems like a worthy RFE to include a pool-wide option to
verify-after-write/commit - to test that recent TXG sync
data has indeed made it to disk on (consumer-grade) hardware
into the designated sector
On Sat, 21 Jan 2012, Jim Klimov wrote:
Regarding the written data, I believe it may find place in the
ARC, and a for the past few TXGs it could still remain there.
Any data in the ARC is subject to being overwritten with updated data
just a millisecond later. It is a live cache.
I am not
2012-01-21 20:50, Bob Friesenhahn wrote:
TXGs get forgotten from memory as soon as they are written.
As I said, that can be arranged - i.e. free the TXG cache
after the corresponding TXG number has been verified?
Point about ARC being overwritten seems valid...
Zfs already knows how to
On Sun, 22 Jan 2012, Jim Klimov wrote:
So far I rather considered flaky hardware with lousy
consumer qualities. The server you describe is likely
to exceed that bar ;)
The most common flaky behavior of consumer hardware which causes
troubles for zfs is not honoring cache-related requests.
2012-01-22 0:55, Bob Friesenhahn wrote:
On Sun, 22 Jan 2012, Jim Klimov wrote:
So far I rather considered flaky hardware with lousy
consumer qualities. The server you describe is likely
to exceed that bar ;)
The most common flaky behavior of consumer hardware which causes
troubles for zfs is
10 matches
Mail list logo
