Closed shuangxia closed 6 years ago
I've done testing on checking the docker mount. It can see the directory on the host within docker container and changes made in one (create new files, mkdir) will reflect on the other.
nvm problem solved. I redirected docker to use the EBS volume instead of the root volume.
What (briefly) did you do? ... just asking because there are two aspects that could cause such an error (1) Osmosis temporary file when parsing the OSM data and (2) the actual database size.
it was the actual database size that caused the issue. My solution is to point docker to the new EBS volume (by doing a soft link from directory to directory), so that any new container data will now be saved on the EBS volume which has more space. After doing so I don't need to change anything about running the docker container itself.
but now I'm thinking of not using docker container as a map server. I'm trying to using an AWS RDS instance instead.
Hi Sebastian, Sorry for bothering you again with more questions... So I'm running the server on an AWS EC2 instance, with a EBS volume mounted to the file system. I did
docker run -it -p 5432:5432 -v /home/ec2-user/barefoot/map_extra:/mnt/map barefoot-map
where/home/ec2-user/barefoot/map_extra
is where I mount the EBS volume, with all the files in the original/barefoot/map
directory. However, then within the container I tried to import an OSM extract which is bigger than the one for testing (germany niedersachsen), and then I gotno space left on device
error. so I guess my question is, does the database take space in the mounted directory? If not, where is it?I don't expect you've seen exactly the same issue before, but any help/advice is much appreciated!
Thanks!