We are running Solaris 10 11/06 on a Sun V240 with 2 CPUS and 8 GB of memory. This V240 is attached to a 3510 FC that has 12 x 300 GB disks. The 3510 is configured as HW RAID 5 with 10 disks and 2 spares and it''s exported to the V240 as a single LUN. We create iso images of our product in the following way (high-level): # mkfile 3g /isoimages/myiso # lofiadm -a /isoimages/myiso /dev/lofi/1 # newfs /dev/rlofi/1 # mount /dev/lofi/1 /mnt # cd /mnt; zcat /product/myproduct.tar.Z | tar xf - and we finally use mkisofs to create the iso image. UFS performance ---------------------- We created a UFS file system on the above LUN and the above iso creation process takes about 5 mins. (I don''t have the exact numbers) ZFS performance --------------------- When we create a ZFS file system on the above LUN and create the iso it takes forever it seems to be hanging in the tar extraction (we killed this after a while i.e. > few hours). My questions are: * are we doing something wrong * is this a known issue * what are the configuration recommendation for a 3510 FC for ZFS Thanks in advance, -- prasad This message posted from opensolaris.org
> We are running Solaris 10 11/06 on a Sun V240 with 2 > CPUS and 8 GB of memory. This V240 is attached to a > 3510 FC that has 12 x 300 GB disks. The 3510 is > configured as HW RAID 5 with 10 disks and 2 spares > and it''s exported to the V240 as a single LUN. > > We create iso images of our product in the following > way (high-level): > > # mkfile 3g /isoimages/myiso > # lofiadm -a /isoimages/myiso > /dev/lofi/1 > # newfs /dev/rlofi/1 > # mount /dev/lofi/1 /mnt > # cd /mnt; zcat /product/myproduct.tar.Z | tar xf - > > and we finally use mkisofs to create the iso image. >> > ZFS performance > --------------------- > When we create a ZFS file system on the above LUN and > create the iso it takes forever it seems to be > hanging in the tar extraction (we killed this after a > while i.e. > few hours).That''s probably bug 6382683 "lofi is confused about sync/async I/O", and AFAIK it''s fixed in current opensolaris releases. See the thread with subject "bad lofi performance with zfs file backend / bad mmap write performance" from january / february 2006: http://mail.opensolaris.org/pipermail/zfs-discuss/2006-January/016450.html http://mail.opensolaris.org/pipermail/zfs-discuss/2006-February/016566.html Possible workaround: Create a 3gb zvol device, and use that instead of a 3gb file + lofi. Or use something like this: zfs create tank/myiso cd /tank/myiso cat /product/myproduct.tar.Z | tar xf - mkisofs ... This message posted from opensolaris.org
On Wed, 28 Mar 2007, prasad wrote:> We create iso images of our product in the following way (high-level): > > # mkfile 3g /isoimages/myiso > # lofiadm -a /isoimages/myiso > /dev/lofi/1 > # newfs /dev/rlofi/1 > # mount /dev/lofi/1 /mnt > # cd /mnt; zcat /product/myproduct.tar.Z | tar xf -How big does your product extract to? Is it close to the 3 gig size of the filesystem? Do you see any difference if you create a 4 gig iso image? Regards, markm
> That''s probably bug 6382683 "lofi is confused about > sync/async I/O", > and AFAIK it''s fixed in current opensolaris > releases. > > See the thread with subject "bad lofi performance > with zfs file backend / > bad mmap write performance" from january / february > 2006: > > http://mail.opensolaris.org/pipermail/zfs-discuss/2006 > -January/016450.html > http://mail.opensolaris.org/pipermail/zfs-discuss/2006 > -February/016566.html > > Possible workaround: > Create a 3gb zvol device, and use that instead of a > 3gb file + lofi. > > Or use something like this: > > zfs create tank/myiso > cd /tank/myiso > cat /product/myproduct.tar.Z | tar xf - > mkisofs ...Thank you for the above information... According to Bug Database bug 6382683 is in 1-Dispatched state, what does that mean? I wonder if the fix is available (or will be available) as a Solaris 10 patch? We have scripts which create our iso images and it will be a too much of a hazzle to modify our scripts with the workaround(s). This sucks, we deployed ZFS into production and roll it back because of this issue. -- prasad This message posted from opensolaris.org
> According to Bug Database bug 6382683 is in 1-Dispatched state, what does that mean?Roughly speaking, the bug has been entered into the database, but no developer has been assigned to it. (State 3 indicates that a developer or team has agreed that it''s a bug; it sounds likely that this bug really ought to be in state 5, since IIRC the cause is well-known. I believe there were some issues with simply changing lofi, since UFS file systems rely on synchronous semantics for their backing store and don''t explicitly flush, but it''s been a while and I don''t recall all of the details.) -- Anton This message posted from opensolaris.org
> > That''s probably bug 6382683 "lofi is confused about sync/async I/O", > > and AFAIK it''s fixed in current opensolaris releases. > > > According to Bug Database bug 6382683 is in > 1-Dispatched state, what does that mean? I wonder if > the fix is available (or will be available) as a > Solaris 10 patch?Seems I was wrong, and this issue is not yet fixed. Yesterday, before replying, I''ve tried to check the state of the bug, but b.o.o. always returned "We encountered an unexpected error. Please try back again." :-( I repeated my test case (creating a pcfs filesystem on a lofi device from an 80gbyte file on zfs), and the write times with a current opensolaris kernel have improved by a factor of 4 (~ 10 seconds instead of 40-50 seconds), but I guess part of the improvement is because of a hardware upgrade here (zpool on two s-ata drives, instead of one p-ata drive). This message posted from opensolaris.org
> On Wed, 28 Mar 2007, prasad wrote: > > > We create iso images of our product in the > following way (high-level): > > > > # mkfile 3g /isoimages/myiso > > # lofiadm -a /isoimages/myiso > > /dev/lofi/1 > > # newfs /dev/rlofi/1 > > # mount /dev/lofi/1 /mnt > > # cd /mnt; zcat /product/myproduct.tar.Z | tar xf - > > How big does your product extract to? Is it close to > the 3 gig size of > the filesystem? Do you see any difference if you > create a 4 gig iso > image? > >We want our iso image to be as small as possible so we create files just a little bigger than what our product would expand to i.e. our product expansion does consume almost 3 gig. I have not tried a 4 gig iso image. Should it be making any difference? -- prasad This message posted from opensolaris.org