[GRASS-user] Splitting a location across several disks

[Dylan Beaudette]

On Wed, Oct 7, 2015 at 3:39 PM, Glynn Clements <glynn at gclements.plus.com> wrote:
>
>
> Dylan Beaudette wrote:
>
> > It has been a while, but glad to be back on GRASS-user.
> >
> > I am working on a project that involves a significant storage dilemma: try
> > and fit most of the files into a 500 Gb SSD for blazing-fast I/O, or fall
> > back to a standard but higher capacity disk drive.
> >
> > Would it be possible to store "derived" data into a mapset that is on
> > standard disk, while the "source" data reside in another mapset, stored on
> > the SSD?
> >
> > In other words, is it OK for a location to contain several mapsets that
> > don't "live" on the same physical disk. It seems like it should work (via
> > symlink), but I would like to see if there are any caveats that I should be
> > aware of.
>
> If symlinks don't work, Linux supports "mount --bind ...", which lets
> you mount a directory from an already-mounted filesystem at another
> location. Windows has similar features (e.g. reparse points), although
> I'm not that familiar with the specifics.
>

Excellent! This is the answer that I was looking for. I will try
symlinks first, otherwise the "mount --bind" strategy is simple
enough. Fortunately this work will be done on linux so just about
anything is possible.

>
> The main constraint is that you can't split a single mapset across
> devices, as it must be possible to rename() files in the .tmp
> subdirectory to other directories withing the mapset, which requires
> that they are on the same physical partition (rename() only
> manipulates directory entries, it won't move the file's data blocks).

OK, good to know.

Is there any reason to think that reading lots of raster files will be
noticeably faster on the SSD?

Thanks,
Dylan

> --
> Glynn Clements <glynn at gclements.plus.com>