bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

loopback readover problem


From: Marcell Gal
Subject: loopback readover problem
Date: Mon, 07 Jan 2002 21:18:09 +0100

Hi guys,

I was experimenting with loopback and crypto
(to check performance when run over a file on an
 inferior nonindexed fat32 filesystem)
and run into the following problem:

when reading over the end of the device vmstat started
to show tremendous 'bi' activity:

- 0  0  0  40552  70956  23284  78876   4   0     4     0  107   246  
0   0 100
 0  0  0  40552  70956  23284  78876   0   0     0     0  101   176  
0   0 100
 0  0  0  40552  70956  23284  78876   0   0     0     0  101   229  
0   0 100
 1  0  0  40552  62280  23284  87468   0   0  8596     0  174   313   2 
27  71
 1  0  0  40552  36936  23284 112812   0   0 25344     0  300   466   0 
70  30
   procs                      memory    swap          io    
system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us 
sy  id
 3  0  0  40552   8056  23284 138412   0   0 25600     0  302   426   3 
68  29
 1  0  0  40676   4360  20224 145764   0 1628 18176  1628  315   518  
1  48  51
 1  0  1  40676   4424  20224 145764   0   0 25600   128  325   720   0 
86  14
 0  1  1  40676   4456  20224 145892   0   0 24832     0  293   712   0 
67  33
 1  1  1  40676   4192  19636 147596   0 208 17664   208  267   536   3 
44  53
 2  0  1  40676   4000  17168 150016   0   0 20480     4  265   621   1 
57  42

 
# dd if=/dev/loop1 of=/tmp/del count=2 skip=709700 bs=1024
2+0 records in
2+0 records out (just OK)
# dd if=/dev/loop1 of=/tmp/del count=2 skip=729700 bs=1024
... because of readover dd never returned!!
When killing dd the abnormal 'bi' activity goes away.

--------------
I straced dd:
...
close(0)                                = 0
open("/dev/loop2", O_RDONLY|0x8000)     = 0
close(1)                                = 0
open("/tmp/del", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0666) = 1
...
fstat64(0, 0xbffffaec)                  = 0
_llseek(0, 736972800, 0xbffffb44, SEEK_CUR) = -1 EINVAL (Invalid
argument)
read(0, "Q\247Q\342+\220T\251\2553\363\300\t\345\23\f\230\345\336"...,
1024) = 1024
read(0, "@\210t\340$\277\224\234\25\377\25\325\20*D\302\270yRc\n"...,
1024) = 1024
read(0, "&address@hidden"...,
1024) = 1024
.......infinite loop....

------------------- System:
Debian 2.3:

ii  fileutils      4.1-7          GNU file management utilities.
ii  libc6          2.2.4-5        GNU C Library: Shared libraries and
Timezone

------------------
Using Linux 2.4.17 kernel with loop-jari-2.4.16.0.patch and
patch-int-2.4.17.0.bz2
international patch.
/dev/loop2: [0307]:1256 (idea-cbc) offset 0, undefined encryption

It seems to be independent of the cipher used.

Should something return some error instead of failing silently?
BTW mke2fs seems to find out the size of the device just OK.
 
Does dd ignore the return value of _llseek()?
Note: I did not experience any instability relating to this.
On the other hand this is perfect for comparing cipher
performance ;-))

what else should I check?
        thanx, guys; GNU's great, keep up the good work:
        Marcell

--
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]