On 08/14/11 12:51 AM, Edward Ned Harvey wrote:
From: Ian Collins [mailto:i...@ianshome.com]
Have you already tested it? Anybody? Or is it still just theoretical
performance enhancement, compared to using a "normal" sized drive in a
normal mode?
How would you test it? I guess you would need
> GNU tar does not follow the standard when creating archives, so Sun
> tar may be unable to unpack the archive correctly.
>
> But GNU tar makes strange things when unpacking symlinks.
>
> I recommend to use star, it understands GNU tar archives.
Even if you used some wierd tar program, the I/O
andy thomas wrote:
> I've tended to use GNU tar on Solaris as apparently there was a bug in the
> Solaris version of tar from very log ago where it would not extract files
> properly from tarfiles created on non-Solaris systems. Maybe this
> long-standing bug has been fixed at last?
This is a
andy thomas wrote:
> So it is GNU tar that is broken and not Solaris tar? I always thought it
> was the other way round. Thanks for letting me know.
Before autoumn 2004, Sun tar had several problems with standard compliance but
then it has been tested against tartest(1) from star.
> > But GN
On Sat, 13 Aug 2011, Joerg Schilling wrote:
andy thomas wrote:
What 'tar' program were you using? Make sure to also try using the
Solaris-provided tar rather than something like GNU tar.
I was using GNU tar actually as the original archive was created on a
Linux machine. I will try it agai
On Sat, 13 Aug 2011, Bob Friesenhahn wrote:
On Sat, 13 Aug 2011, andy thomas wrote:
However, one of our users recently put a 35 Gb tar.gz file on this server
and uncompressed it to a 215 Gb tar file. But when he tried to untar it,
after about 43 Gb had been extracted we noticed the disk usage
On Thu, Aug 11, 2011 at 11:14 AM, Test Rat wrote:
> After replicating a pool with zfs send/recv I've found out I cannot
> perform some zfs on those datasets anymore. The datasets had permissions
> set via `zfs allow'.
>
...
>
> So, what are permissions if not properties?
Properties are things
andy thomas wrote:
> > What 'tar' program were you using? Make sure to also try using the
> > Solaris-provided tar rather than something like GNU tar.
>
> I was using GNU tar actually as the original archive was created on a
> Linux machine. I will try it again using Solaris tar.
GNU tar does
On Sat, 13 Aug 2011, Bob Friesenhahn wrote:
On Sat, 13 Aug 2011, andy thomas wrote:
However, one of our users recently put a 35 Gb tar.gz file on this server
and uncompressed it to a 215 Gb tar file. But when he tried to untar it,
after about 43 Gb had been extracted we noticed the disk usage
On Sat, 13 Aug 2011, andy thomas wrote:
However, one of our users recently put a 35 Gb tar.gz file on this server and
uncompressed it to a 215 Gb tar file. But when he tried to untar it, after
about 43 Gb had been extracted we noticed the disk usage reported by df for
that ZFS pool wasn't chang
> From: Ian Collins [mailto:i...@ianshome.com]
> Sent: Friday, August 12, 2011 11:24 PM
>
> >> For ZIL, I
> >> suppose we could get the 300GB drive and overcommit to 95%!
> > What kind of benefit does that offer? I suppose, if you have a 300G
drive
> > and the OS can only see 30G of it, then the
> Does setting the aclinherit=passthrough-x zfs property on the
> filesystem help?
I'll try that once I'm back at the office - thanks!
> I'm not sure, but you may still need to do a chmod -R on each
> filesystem to set the ACLs on each existing directory.
I'll try the one above first...
Vennlig
On 12 Aug 2011, at 21:47, Roy Sigurd Karlsbakk wrote:
> Hi all
>
> We've migrated from an old samba installation to a new box with openindiana,
> and it works well, but... It seems Windows now honours the executable bit, so
> that .exe files for installing packages, are no longer directly exec
Hiya,
I am trying to add shares to my Win7 libraries but Windows won't let me add
them due to them not being indexed.
Does S11E have any server-side indexing feature?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss
We are using ZFS on a Sun E450 server (4 x 400 MHz CPU, 1 Gb memory, 18 Gb
system disk and 19 x 300 Gb disks running OSOL snv 134) for archive
storage where speed is not important. We have 2 RAID-Z1 pools of 8 disks
plus one spare disk shared between the two pools and this has apparently
worked
15 matches
Mail list logo
