Quantcast

Can newExtent accept zipped extents?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Can newExtent accept zipped extents?

GLASS mailing list
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can newExtent accept zipped extents?

GLASS mailing list


On Fri, Jan 27, 2017 at 5:02 PM, Mariano Martinez Peck <[hidden email]> wrote:
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

Actually, I would be able to pass both:

1) a zip of the extent0.dbf
2) the result of SystemRepository fullBackupCompressedTo:  

Thanks

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can newExtent accept zipped extents?

GLASS mailing list
In reply to this post by GLASS mailing list

Mariano,

That should be possible ... submit an issue up on GsDevKit_home and I will look into it ...

Dale


On 01/27/2017 12:02 PM, Mariano Martinez Peck via Glass wrote:
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can newExtent accept zipped extents?

GLASS mailing list
In reply to this post by GLASS mailing list

Since I've started work on this, I've opened a bug[1]

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/issues/162


On 1/27/17 12:03 PM, Mariano Martinez Peck via Glass wrote:


On Fri, Jan 27, 2017 at 5:02 PM, Mariano Martinez Peck <[hidden email]> wrote:
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

Actually, I would be able to pass both:

1) a zip of the extent0.dbf
2) the result of SystemRepository fullBackupCompressedTo:  

Thanks

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can newExtent accept zipped extents?

GLASS mailing list
Cool! Thanks for already starting the work (sorry I was away from my computer to open the issue).
Not for putting pressure but just to see how to organize my work for the next week, do you have an idea more or less on when this could be available (in gs_port?) ?

Thanks a lot in advance,

On Fri, Jan 27, 2017 at 9:59 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Since I've started work on this, I've opened a bug[1]

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/issues/162


On 1/27/17 12:03 PM, Mariano Martinez Peck via Glass wrote:


On Fri, Jan 27, 2017 at 5:02 PM, Mariano Martinez Peck <[hidden email]> wrote:
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

Actually, I would be able to pass both:

1) a zip of the extent0.dbf
2) the result of SystemRepository fullBackupCompressedTo:  

Thanks

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can newExtent accept zipped extents?

GLASS mailing list

It turns out that this work shouldn't be that difficult ... I'm hoping to have something later today:)

Dale


On 1/27/17 6:04 PM, Mariano Martinez Peck wrote:
Cool! Thanks for already starting the work (sorry I was away from my computer to open the issue).
Not for putting pressure but just to see how to organize my work for the next week, do you have an idea more or less on when this could be available (in gs_port?) ?

Thanks a lot in advance,

On Fri, Jan 27, 2017 at 9:59 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Since I've started work on this, I've opened a bug[1]

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/issues/162


On 1/27/17 12:03 PM, Mariano Martinez Peck via Glass wrote:


On Fri, Jan 27, 2017 at 5:02 PM, Mariano Martinez Peck <[hidden email]> wrote:
Hi Dale,

I have one me my stones outside gsDevKit with a large size (55GB). I am moving this stone to be gsDevKit managed and the first thing I must do is this:

createStone -fg -U $stoneUsername -P $stonePass -s /quuve/sites/$sourceStoneName/gemstone/data/extent0.dbf $sourceStoneName 3.2.9

The problem is that underneath it uses `newExtent`  to copy the dbf. See this code in `newExtent`:

 echo "Copy snapshot and remove tranlogs"
  $GS_HOME/bin/devKitCommandLine newExtent $stoneName $snapshotFile


That means...I would need yet another 55GB free (without couting the backups when tODE is installed..which I know how to avoid), which I don't have. 

Is it possible for " $GS_HOME/bin/devKitCommandLine newExtent " to accept compressed (gz) dbf?  That way, I can compress my original and pass the .gz.dbf.

Thanks in advance, 

 

Actually, I would be able to pass both:

1) a zip of the extent0.dbf
2) the result of SystemRepository fullBackupCompressedTo:  

Thanks

--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass
--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Metacello load order of dependant projects

GLASS mailing list
In reply to this post by GLASS mailing list
Am I able to specify the order in which project dependencies load in a baseline? I am loading a version of Seaside locally from disc and have the following in the baseline...

     spec
        baseline: 'Seaside3'
        with: [
          spec
            repository:
                'filetree:///opt/git/JupiterSmalltalk/Seaside/repository';
            loads: #('Core' 'Development' 'Zinc') ]
      spec
        configuration: 'Bootstrap'
        with: [
          spec
            repository:
                'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main';
            version: '0.16.0' ].
      spec
        configuration: 'BootstrapMagritte'
        with: [
          spec
            repository:
                'http://www.smalltalkhub.com/mc/TorstenBergmann/BootstrapMagritte/main';
            version: '0.2.3’ ]

However, Metacello ends up trying to load Bootstrap first which loads Seaside from Smalltalkhub.

I can manually load Seaside first, then lock it, then load this baseline, however, if it possible to make it load the seaside from this baseline first and lock it?

Thanks for any advice.

Cheers,

J
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Metacello load order of dependant projects

GLASS mailing list
Jupiter,

Executing the following before loading should do the trick:

   Metacello new
     baseline: 'Seaside3';
     repository: 'filetree:///opt/git/JupiterSmalltalk/Seaside/repository';
     lock.

This will force Bootstrap and/or BootstrapMaggritte to load Seaside3
from your local repository ...If you have local clones, you should be
using a lock, you can use a lock like the one above without loading the
project ...

<aside>With tODE putting project entries with a lock into
$GS_HOME/sys/local/server/projects will automatically lock those
projects (if you either use `project load` to load projects or have
executed a `project list` at least once... and then subsequent loads via
Metacello or tODE will honor the locked projects ... the idea is to not
require you to always have to worry about doing manual 'lock" commands
for all of your local clones for each new stone that you create</aside>

With the lock ,you probably don't need to include the Seaside3 baseline
spec below unless you have another direct dependency on the Seaside3
project ... the lock (without a load) is sufficient and a load of any
project that references Seasidde3 or any other locked project will
automatically use the local clone ...

The code that included below does not look like a complete baseline spec
... what class is it in? are there any package specs?what is your load
command?

There are just three project references that I see: Seaside3, Bootstrap,
and BootstrapMagritte. Without the actual load expression and complete
baseline spec, I can't really tell what Metacello will try to load ...

For example the default order for an expression like

   Metacello new
     baseline: '???';
     repository: '???';
     load.

Should be definition order and since Seaside3 is the first definition I
see it should be first, but it sounds like you might be doing something
like:

   Metacello new
     baseline: '???';
     repository: '???';
     load: `Bootstrap'.

or there is more in the baseline spec than meets my eye:)

Dale


On 2/9/17 3:27 PM, Jupiter Jones via Glass wrote:

> Am I able to specify the order in which project dependencies load in a baseline? I am loading a version of Seaside locally from disc and have the following in the baseline...
>
>       spec
>          baseline: 'Seaside3'
>          with: [
>            spec
>              repository:
>                  'filetree:///opt/git/JupiterSmalltalk/Seaside/repository';
>              loads: #('Core' 'Development' 'Zinc') ]
>        spec
>          configuration: 'Bootstrap'
>          with: [
>            spec
>              repository:
>                  'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main';
>              version: '0.16.0' ].
>        spec
>          configuration: 'BootstrapMagritte'
>          with: [
>            spec
>              repository:
>                  'http://www.smalltalkhub.com/mc/TorstenBergmann/BootstrapMagritte/main';
>              version: '0.2.3’ ]
>
> However, Metacello ends up trying to load Bootstrap first which loads Seaside from Smalltalkhub.
>
> I can manually load Seaside first, then lock it, then load this baseline, however, if it possible to make it load the seaside from this baseline first and lock it?
>
> Thanks for any advice.
>
> Cheers,
>
> J
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Loading...