> "es" == Eric Schrock <[EMAIL PROTECTED]> writes:
es> Are you running your experiments on build 101 or later?
no.
aside from that quick one for copies=2 im pretty bad about running
well-designed experiments. and I do have old builds. I need to buy
more hardware.
It's hard to know how
dick hoogendijk <[EMAIL PROTECTED]> wrote:
> And in the meantime the solution to the broken cpio command like this:
>
> cd /backup
> find . -depth -print | cpio -pdmvu /pool
>
> What would be the correct pax syntax?
star fs=128m -copy -p -U -sparse -C /backup . /pool
Jörg
--
EMail:[EMAIL PROT
[EMAIL PROTECTED] wrote:
> I've upped the priority, accepted the bug and moved it to the proper
> category (utility/archiver).
>
> I've run cpio from all builds which changed cpio and the first
> broken build is snv_81.
At this time, 30% of the code have been changed. This was a real big change.
On 28 Nov 2008, at 00:07, Peter Brouwer, Principal Storage Architect
wrote:
>
>
> dick hoogendijk wrote:
>>
>> On Thu, 27 Nov 2008 12:58:20 +
>> Chris Ridd <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I'm not 100% convinced it'll boot if half the mirror's not there,
>>>
>> Believe me, it will (been
On Fri, 28 Nov 2008 17:36:22 +0100
[EMAIL PROTECTED] wrote:
> >>Absolutely weird; the "cpio -p" doesn't use any intermediate archive
> >>format and it should be able to copy files of any size.
> >
> >It works in Solaris 10u5 so it's broken later (Nevada?) at some
> >point in time...
>
> I've uppe
>
>
>>Absolutely weird; the "cpio -p" doesn't use any intermediate archive
>>format and it should be able to copy files of any size.
>
>
>It works in Solaris 10u5 so it's broken later (Nevada?) at some point in
>time...
I've upped the priority, accepted the bug and moved it to the proper
categ
Ross Smith wrote:
> On Fri, Nov 28, 2008 at 5:05 AM, Richard Elling <[EMAIL PROTECTED]> wrote:
>
>> Ross wrote:
>>
>>> Well, you're not alone in wanting to use ZFS and iSCSI like that, and in
>>> fact my change request suggested that this is exactly one of the things that
>>> could be addre
>Absolutely weird; the "cpio -p" doesn't use any intermediate archive
>format and it should be able to copy files of any size.
It works in Solaris 10u5 so it's broken later (Nevada?) at some point in
time...
Casper
___
zfs-discuss mailing list
zfs
Udo Grabowski wrote:
> Ok, your procedure differs slightly from what I've done:
> zfs import -f rpool
> zfs set mountpoint=/a rpool/ROOT/opensolaris
> ls -l /a
>
> Setting mountpoint AND explicitly mounting indeed gives the files back !
>
> I didn't mount it explicitly after setting mountpoint
>cd /backup
>find . -depth -print | cpio -pdmvu /pool
><...lots of files listed>
> blocks copied
>
>I've filed a bug report on it now.
>
>The limit is 4GB, not 2 as I believed last night. It's simple to=20
>reproduce:
>
>mkdir test
>mkfile 4200m bigfile
>echo bigfile | cpio -pdmvu test/
>echo $?
>
On Fri, 28 Nov 2008, Joerg Schilling wrote:
Håkan Olsson <[EMAIL PROTECTED]> wrote:
I was just restoring a bunch of files from backup using find|cpio when I
noticed that cpio does not copy files >2GB properly. The resulting files
were "oddly" sized ( % 2GB, perhaps?).
Even more alarming, cpio
Ok, your procedure differs slightly from what I've done:
zfs import -f rpool
zfs set mountpoint=/a rpool/ROOT/opensolaris
ls -l /a
Setting mountpoint AND explicitly mounting indeed gives the files back !
I didn't mount it explicitly after setting mountpoint to /a, since it used to be
mounted auto
Håkan Olsson <[EMAIL PROTECTED]> wrote:
> I was just restoring a bunch of files from backup using find|cpio when I
> noticed that cpio does not copy files >2GB properly. The resulting files
> were "oddly" sized ( % 2GB, perhaps?).
>
> Even more alarming, cpio did not warn in any way about not co
13 matches
Mail list logo
