scidb::SCIDB_SE_IO::SCIDB_LE_PWRITE_ERROR


#1

What does scidb::SCIDB_SE_IO::SCIDB_LE_PWRITE_ERROR mean? My redimension operation fails with

SystemException in file: src/util/FileIO.cpp function: writeAllv line: 304
Error id: scidb::SCIDB_SE_IO::SCIDB_LE_PWRITE_ERROR
Error description: I/O error. pwrite failed to write 3216848 byte(s) to the position 3900702720 with error 2.


#2

Bonsai?

Quick question? Which version are you on?

I think this is a bug that we fixed a version or so back.


#3

I’m using 14.8 from the Ubuntu repository on an Ubuntu 12.04.5 LTS.


#4

In the release following 14.8, this problem is solved, in the sense that: (a) In some cases the error does not occur anymore; and (b) If SciDB cannot deal with it, e.g. if you run out of disk space, SciDB will throw a more informative error such as including the err string and the file where the write failed.

Until then, there is something you could check. We witnessed that at least in one case, the same error in 14.8 occurred because the temp space was filled. The solution in that case was to remove the config.ini line that defines ‘tmp-path’. Note that if you do not explicitly define it, the default behavior is that every SciDB instance keeps temp files in a sub-directory of its data directory (typically large). But if you define it with an absolute path e.g. ‘=/tmp’, the temp directory will be /tmp which is typically small and may overflow; worse, all SciDB instances on the same machine will compete for the same /tmp directory.

So open config.ini and check. If there is a line defining ‘tmp-path’, stop SciDB, remove the line from config.ini, and restart SciDB.


#5

I don’t have a tmp-path setting in my config and the tmp folder seems to be inside the scidb data directory. That directory is on a mount with 150GB of space and I want to load 50 GB of binary data and redimension it. The machine has 16 GB of RAM.
Is there a factor to compute the approximate required tmp space and the approximate required space scidb needs for storing the data?


#6

I see.
We do not have an exact factor of how much tmp space is needed to complete a redimension query, partly because the factor varies depending on data (dimensionality; sparsity; etc.)
But for 50GB data, 150GB is obviously not enough. Maybe a factor of 5 will do it.


#7

[quote=“donghui”]I see.
We do not have an exact factor of how much tmp space is needed to complete a redimension query, partly because the factor varies depending on data (dimensionality; sparsity; etc.)
But for 50GB data, 150GB is obviously not enough.[/quote]
How is this obvious if it’s hard to give a factor? Or do you mean obvious from the fact that the redim failed with a write error?

It turned out that a factor of 5 per machine was necessary - I used 2 machines so that’s a total factor of 10.

Since my current experiments are only a test case with a “small” dataset, what’s your recommended course of action for handling large datasets? Say I want to handle 10 TB of this kind of data but it turns out I need 100 TB of temp space to redimension it. If I don’t have 100 TB to do this, I shouldn’t use SciDB?


#8

It turned out that a factor of 5 per machine was necessary - I used 2 machines so that’s a total factor of 10.
I am not sure I understand your logic …
If you use 2 machines (I assume, at least two instances across two physical boxes), you are correct that you need ~5x temp space per instance to redimension a given array. However, the total extra capacity is still 5x because the data are distributed across all the instances (unless I am missing something).
If I don’t have 100 TB to do this, I shouldn’t use SciDB?
We obviously prefer that you do use SciDB :smile:. So, to redimension large amounts of data, you could split the loads into smaller chunks and load incrementally via either:
(preferred) for all data fragments
load(…,RAW_FRAGMENT), insert(redimension(RAW_FRAGMENT,REGION),TGT)
OR
for all data fragments
insert(redimension(input(RAW_FRAGMENT,…),REGION),TGT)
The final TGT array should be roughly equal to the input data (subject to various factors, it may also be much smaller because of compression).
Take a look at paradigm4.com/HTMLmanual/14. … /ch08.html for further help on loading.
Hope this helps.


#9

[quote=“tigor”]>It turned out that a factor of 5 per machine was necessary - I used 2 machines so that’s a total factor of 10.
I am not sure I understand your logic …
If you use 2 machines (I assume, at least two instances across two physical boxes), you are correct that you need ~5x temp space per instance to redimension a given array. However, the total extra capacity is still 5x because the data are distributed across all the instances (unless I am missing something).[/quote]
I also get a feeling I don’t understand you correctly. If I try to load 50 GB of data and need 250GB PER machine to do that, and I have 2 machines, that’s still 500 GB of disk space and thus 10x as much as the original data. Since I have to have the 2 machines running concurrently, I need 500 GB of space available during my load. Am I overlooking s.th.?

[quote]So, to redimension large amounts of data, you could split the loads into smaller chunks and load incrementally via either:
(preferred) for all data fragments
load(…,RAW_FRAGMENT), insert(redimension(RAW_FRAGMENT,REGION),TGT)
OR
for all data fragments
insert(redimension(input(RAW_FRAGMENT,…),REGION),TGT)
[/quote]
I’ll try, but a colleague of mine has problems with this approach.

Well, if I load my 50 GB binary data set, my target array uses 35GB of space on each of the 2 machines, so ~70GB in total.
I’m wondering if I can do something to improve the “compression” here.