Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

размер файла- архива 0

19 views
Skip to first unread message

Tatiana Ilinikh

unread,
Feb 18, 2002, 5:01:34 AM2/18/02
to
Здравствуйте!

У на IDS 2000 9.21 под Linux'ом.
Пытаюсь записать архив 0-уровня в файл(
т.е. в качестве TAPEDEV использую имя файла
ОС). При достижении файлом размера 2G получаю
сообщение "File size limit exceeded", несмотря на то, что
в Linux'е такого ограничения на размер файла нет.
Мало того, восстановление из архива-0 выполняется
при размере архивного файла более 3G.
Что бы это значило?

С уважением.
Ita.

yurik shestakov

unread,
Feb 18, 2002, 5:48:54 AM2/18/02
to
Tatiana Ilinikh <i...@lanta.kts.ru> wrote:
TI> Здравствуйте!

TI> У на IDS 2000 9.21 под Linux'ом.
TI> Пытаюсь записать архив 0-уровня в файл(
TI> т.е. в качестве TAPEDEV использую имя файла
TI> ОС). При достижении файлом размера 2G получаю
TI> сообщение "File size limit exceeded", несмотря на то, что
TI> в Linux'е такого ограничения на размер файла нет.
TI> Мало того, восстановление из архива-0 выполняется
TI> при размере архивного файла более 3G.
TI> Что бы это значило?

Это значит 2 вещи.
Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
доступ к файлам. Отсюда лимит в 2G.

Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
делать многотомный архив.

--
// yurik shestakov for mail: yu-at-frigate_kiev_ua

serge

unread,
Feb 19, 2002, 9:54:44 AM2/19/02
to
yurik shestakov wrote:

Либо писать в fifo. А на другом конце канала можно и сжимать перед
сохранением в файл.

yurik shestakov

unread,
Feb 19, 2002, 10:06:12 AM2/19/02
to
serge <se...@real.kharkov.ua> wrote:
s> yurik shestakov wrote:

>> TI> в Linux'е такого ограничения на размер файла нет.
>> TI> Мало того, восстановление из архива-0 выполняется
>> TI> при размере архивного файла более 3G.
>> TI> Что бы это значило?
>>
>> Это значит 2 вещи.
>> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>> доступ к файлам. Отсюда лимит в 2G.
>>
>> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> делать многотомный архив.
>>
>>

s> Либо писать в fifo. А на другом конце канала можно и сжимать перед
s> сохранением в файл.

У кого такой вариант заработал под Linux ?
В смысле чтобы потом можно было прочитать-восстановить то,
что через pipe получено.

Vasyl Shulzhenko

unread,
Feb 19, 2002, 10:24:16 AM2/19/02
to

"yurik shestakov" <yu4...@frigate.kiev.ua> wrote in message
news:a4qm6m$ijj$1...@news.lucky.net...

> Tatiana Ilinikh <i...@lanta.kts.ru> wrote:
> TI> Здравствуйте!
>
> TI> У на IDS 2000 9.21 под Linux'ом.
> TI> Пытаюсь записать архив 0-уровня в файл(

А если на ленту, то проблем нет ?

> TI> т.е. в качестве TAPEDEV использую имя файла
> TI> ОС). При достижении файлом размера 2G получаю
> TI> сообщение "File size limit exceeded", несмотря на то, что
> TI> в Linux'е такого ограничения на размер файла нет.
> TI> Мало того, восстановление из архива-0 выполняется
> TI> при размере архивного файла более 3G.
> TI> Что бы это значило?
>
> Это значит 2 вещи.
> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
> доступ к файлам. Отсюда лимит в 2G.

Странно, WinNT тоже 32-битная ОС, тем не менее я могу создавать ontape-ом
файл размером в 8-9G.

> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
> делать многотомный архив.

Для файла на диске, боюсь, не поможет.

--

С уважением,

Василий Шульженко
http://softline.kiev.ua


serge

unread,
Feb 19, 2002, 10:20:07 AM2/19/02
to
yurik shestakov wrote:

У меня. IDS 7.30UC10 + kernel 2.4.9-13 + glibc 2.2.4

1. mkfifo /opt/informix/backup.fifo

2. ONCONFIG :

[..]
TAPEDEV /opt/informix/backup.fifo # Tape device path
TAPEBLK 32 # Tape block size (Kbytes)
TAPESIZE 12000000 # Maximum amount of data to put on tape
[..]

3. бэкап :
на одной консоли даешь gzip </opt/informix/backup.fifo > [somefile],
на другой ontape -s

4. востановление :
на одной консоли
for i in 1 2 ; do
gunzip < [somefile] > /opt/informix/backup.fifo
done

на другой ontape -r

И ничего, работает.


yurik shestakov

unread,
Feb 19, 2002, 10:47:26 AM2/19/02
to
serge <se...@real.kharkov.ua> wrote:
s> yurik shestakov wrote:

>> serge <se...@real.kharkov.ua> wrote:
>> s> yurik shestakov wrote:
>>
>>
>>>> TI> в Linux'е такого ограничения на размер файла нет.
>>>> TI> Мало того, восстановление из архива-0 выполняется
>>>> TI> при размере архивного файла более 3G.
>>>> TI> Что бы это значило?
>>>>
>>>>Это значит 2 вещи.
>>>>Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>>>>есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>>>>доступ к файлам. Отсюда лимит в 2G.
>>>>
>>>>Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>>>>делать многотомный архив.
>>>>
>>>>
>>>>
>>
>> s> Либо писать в fifo. А на другом конце канала можно и сжимать перед
>> s> сохранением в файл.
>>
>> У кого такой вариант заработал под Linux ?
>> В смысле чтобы потом можно было прочитать-восстановить то,
>> что через pipe получено.

s> У меня. IDS 7.30UC10 + kernel 2.4.9-13 + glibc 2.2.4

s> 1. mkfifo /opt/informix/backup.fifo

Ага, у меня на 2.2.x ядрах получались битые многотомные архивы.
Надо попробовать по-новой. А то пока "извращаюсь" через файлы,
но работает железно.

s> 2. ONCONFIG :

s> [..]
s> TAPEDEV /opt/informix/backup.fifo # Tape device path
s> TAPEBLK 32 # Tape block size (Kbytes)
s> TAPESIZE 12000000 # Maximum amount of data to put on tape
s> [..]

12G -- не слишком ли "круто" ? ;-)
Хотя должно работать через fifo.

s> 3. бэкап :
s> на одной консоли даешь gzip </opt/informix/backup.fifo > [somefile],
s> на другой ontape -s

s> 4. востановление :
s> на одной консоли
s> for i in 1 2 ; do
s> gunzip < [somefile] > /opt/informix/backup.fifo
s> done

s> на другой ontape -r

s> И ничего, работает.

yurik shestakov

unread,
Feb 19, 2002, 10:50:58 AM2/19/02
to
Vasyl Shulzhenko <vas...@mail.ru> wrote:

>>
>> Это значит 2 вещи.
>> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>> доступ к файлам. Отсюда лимит в 2G.

VS> Странно, WinNT тоже 32-битная ОС, тем не менее я могу создавать ontape-ом
VS> файл размером в 8-9G.

Я говорил об двух группах ф-й для работы с файлами: lseek, например.
Реально lseek -- это макрос. Какая ф-я реально вызывается -- зависит
от версии glibc, от наличия/отсутствия определенного __USE_LARGEFILE64

>> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> делать многотомный архив.

VS> Для файла на диске, боюсь, не поможет.

Что не поможет? У меня размер TAPESIZE=128M

Vasyl Shulzhenko

unread,
Feb 20, 2002, 5:45:52 AM2/20/02
to

"yurik shestakov" <yu4...@frigate.kiev.ua> wrote in message
news:a4ts92$i5c$2...@news.lucky.net...
> Vasyl Shulzhenko <vas...@mail.ru> wrote:

> >> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
> >> делать многотомный архив.
> VS> Для файла на диске, боюсь, не поможет.
> Что не поможет? У меня размер TAPESIZE=128M

Я не учел платформу. Просто на Винде нельзя сделать многотомный архив в файл
:(

Кстати, а зачем тебе такой маленький размер тома ?


yurik shestakov

unread,
Feb 20, 2002, 6:05:47 AM2/20/02
to
Vasyl Shulzhenko <vas...@mail.ru> wrote:

>> >> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> >> делать многотомный архив.
>> VS> Для файла на диске, боюсь, не поможет.
>> Что не поможет? У меня размер TAPESIZE=128M

VS> Я не учел платформу. Просто на Винде нельзя сделать многотомный архив в
VS> файл :(

VS> Кстати, а зачем тебе такой маленький размер тома ?

Меня не смущает 30-40 томов при L0-архиве :)
Хотя лучше -- меньше :)

serge

unread,
Feb 20, 2002, 6:24:31 AM2/20/02
to
yurik shestakov wrote:


На предыдущих ядрах нужны были дополнительные пляски с бубном :

1. onconfig :

TAPEBLK 4 # Tape block size (Kbytes)


4 Кб - минимальный поддерживаемый Informix.

2. Пишем небольшую программку на C (впрочем дело вкуса). Назначение -
буферизация потока при чтении:

blockread.c, copyright by Михаил Куринной :

#include <unistd.h>
#include <stdlib.h>

main(int argc, char *argv[]){
int blocksize = atoi(argv[1]);
char *buffer = malloc(blocksize);
while(1){
int bs = blocksize;
while(bs){
int n = read(0, buffer+blocksize-bs, bs);
if (!n) break;
bs -= n;
}
write(1, buffer, blocksize-bs);
if (bs) break;
}

3. компилируем :
gcc blockread.c -o blockread

4. И теперь команда на восстановление :

for i in 1 2 ; do

gunzip < [somefile] | blockread 4096 > /opt/informix/backup.fifo

done
4096 в параметре blockread - количество байт в TAPEBLK из onconfig.

На других размерах размера блока эта технология работать не хотела.
Впрочем дело давнее и я наверняка не помню.


>
> s> 2. ONCONFIG :
>
> s> [..]
> s> TAPEDEV /opt/informix/backup.fifo # Tape device path
> s> TAPEBLK 32 # Tape block size (Kbytes)
> s> TAPESIZE 12000000 # Maximum amount of data to put on tape
> s> [..]
>
> 12G -- не слишком ли "круто" ? ;-)
> Хотя должно работать через fifo.


Да в том то и дело что с fifo связались из-за того что места под
выгрузку на диске не хватало. Вот и пришлось сжимать на лету.

0 new messages