The UNIX and Linux Forums  

Go Back   The UNIX and Linux Forums > Top Forums > UNIX for Advanced & Expert Users
Google UNIX.COM


UNIX for Advanced & Expert Users Advanced UNIX and Linux questions go here. Expert-to-Expert.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
server seek internet ariec AIX 0 06-05-2008 12:20 AM
Add faceted search to Thunderbird with Seek iBot UNIX and Linux RSS News 0 04-21-2008 01:50 AM
seek-1f42 1.46 (Default branch) iBot Software Releases - RSS News 0 03-19-2008 05:30 PM
seek-h262 4.84 (Default branch) iBot Software Releases - RSS News 0 02-02-2008 08:40 PM
Why script For...Loop doesn't work. Seek help duke0001 UNIX for Dummies Questions & Answers 3 10-16-2006 01:22 PM

Reply
 
Submit Tools LinkBack Thread Tools Search this Thread Display Modes
  #1  
Old 08-29-2008
Registered User
 

Join Date: Aug 2008
Posts: 5
dd seek problem

I want to seek to a location on the hard drive that will be written to that is different from the output block size. Is this possible? It seems the man page implies you can only seek in increments of the number of bytes you output.

A bit of information about what I'm trying to do, if that helps. Maybe I need to use another unix command I don't know of:

I'm trying to do is to seek to a point on a hard drive and write to it in block sizes that will not page. So, if I seek to a point on the hard drive that is larger than my ram, that would be the default block size to write, then I believe I will get paging.

Last edited by silvermoon; 08-29-2008 at 09:42 AM.
Reply With Quote
Forum Sponsor
  #2  
Old 08-30-2008
era era is offline
Herder of Useless Cats
 

Join Date: Mar 2008
Location: /there/is/only/bin/sh
Posts: 3,650
You can seek to any point with dd, it's not tied to the hardware's block size; you can set bs to anything (for example, one).

I don't understand your explanation of why you think this would be useful, though.
Reply With Quote
  #3  
Old 08-31-2008
Registered User
 

Join Date: Aug 2008
Posts: 5
Quote:
Originally Posted by era View Post
You can seek to any point with dd, it's not tied to the hardware's block size; you can set bs to anything (for example, one).

I don't understand your explanation of why you think this would be useful, though.
If I set bs to 1, like you say, wouldn't it then only read and write one byte per count? If I am not misled on this, the data would be copied slowly due to dd handling 1 byte per count iteration.

What I find is confusing is that dd man page seems to imply I can only seek in obs. Which makes it seem that if I decide I want to write with a megabyte at a time (so do more per count iteration), I can only seek a megabyte at a time, which results in not being able to seek any where I want.

I hope I'm confused, because dd won't work for me if this is true. Unless there is a workaround.
Reply With Quote
  #4  
Old 08-31-2008
era era is offline
Herder of Useless Cats
 

Join Date: Mar 2008
Location: /there/is/only/bin/sh
Posts: 3,650
I think your interpretation of "seek" is wrong. It means to skip to the requested position.

Code:
vnix$ time dd if=/dev/zero bs=9876542 seek=42 count=1 of=/dev/null
1+0 records in
1+0 records out
9876542 bytes (9,9 MB) copied, 0,000559297 seconds, 17,7 GB/s

real    0m0.206s
user    0m0.004s
sys     0m0.004s
As you can tell by the byte count, it really only reads after seeking.

You are correct that the seek parameter expresses how many blocks to seek forward, but on a block device, this truly is a seek operation (move the disk head to the requested position), not a serial operation.

Of course, if you mean to read a lot of data after the seek operation, then the block size does affect the read, but I don't think it modifies the hardware buffer block size, i.e. slow down buffered reads.

Last edited by era; 08-31-2008 at 08:23 AM. Reason: On reading after seeking
Reply With Quote
  #5  
Old 08-31-2008
Registered User
 

Join Date: Aug 2008
Posts: 5
Quote:
Originally Posted by era View Post
I think your interpretation of "seek" is wrong. It means to skip to the requested position.

Code:
vnix$ time dd if=/dev/zero bs=9876542 seek=42 count=1 of=/dev/null
1+0 records in
1+0 records out
9876542 bytes (9,9 MB) copied, 0,000559297 seconds, 17,7 GB/s

real    0m0.206s
user    0m0.004s
sys     0m0.004s
As you can tell by the byte count, it really only reads after seeking.

You are correct that the seek parameter expresses how many blocks to seek forward, but on a block device, this truly is a seek operation (move the disk head to the requested position), not a serial operation.

Of course, if you mean to read a lot of data after the seek operation, then the block size does affect the read, but I don't think it modifies the hardware buffer block size, i.e. slow down buffered reads.
Maybe an example will help narrow things this problem down.

I used a jpg to copy to make it easy to check for errors.

I copied the file to a usb memory stick with no partition table, (zeroed out). First I tried without seeking or skipping and all worked fine. The jpg opened fine.

Code:
x@hugin:~$ sudo dd if=/home/x/Desktop/omp.jpg of=/dev/sdb count=1 ibs=281881
1+0 records in
550+1 records out
281881 bytes (282 kB) copied, 0.740358 seconds, 381 kB/s

x@hugin:~$ sudo dd if=/dev/sdb of=/home/x/Desktop/p.jpg count=1 ibs=281881
1+0 records in
550+1 records out
281881 bytes (282 kB) copied, 0.493491 seconds, 571 kB/s
But, once I tried using seek and skip, the jpg would not open:

Code:
x@hugin:~$ sudo dd if=/home/x/Desktop/omp.jpg of=/dev/sdb seek=1 count=1 ibs=281881
1+0 records in
550+1 records out
281881 bytes (282 kB) copied, 0.722257 seconds, 390 kB/s

x@hugin:~$ sudo dd if=/dev/sdb of=/home/x/Desktop/p.jpg skip=1 count=1 ibs=281881
1+0 records in
550+1 records out
281881 bytes (282 kB) copied, 0.48324 seconds, 583 kB/s
I am assuming that skip mean to advance along the destination before writing and skip means to advance along the medium where things will be read before reading, but I'm not getting a readable jpg.
Reply With Quote
  #6  
Old 08-31-2008
era era is offline
Herder of Useless Cats
 

Join Date: Mar 2008
Location: /there/is/only/bin/sh
Posts: 3,650
Can you examine the resulting file? I assume you get the result from the first experiment in the first 281,881 bytes after the second operation, and its contents are 2 x 281,881 bytes (but of course, in the absence of a file system, it's hard to tell). What about when you copy it back, do you get padding on either end of the file, or the wrong number of bytes, or the wrong contents?
Reply With Quote
  #7  
Old 08-31-2008
Registered User
 

Join Date: Aug 2008
Posts: 5
Quote:
Originally Posted by era View Post
Can you examine the resulting file? I assume you get the result from the first experiment in the first 281,881 bytes after the second operation, and its contents are 2 x 281,881 bytes (but of course, in the absence of a file system, it's hard to tell). What about when you copy it back, do you get padding on either end of the file, or the wrong number of bytes, or the wrong contents?
When it's copied back, I get the same size file. When I view the contents of the file, it has got the last few hundred bytes of the jpg. The rest of the file is zero's that were placed on the memory stick before the copy operation occurred.

I finally realized that default 550 obs was the issue when combined with skip, whereas seek used 281881.


The program I'm writing is in Python. My goal is to write a file at any location I want on any drive. It's part of an encryption idea, where the encryption decides where to store the file rather than the file management system. That's when I need to seek a number of bytes that isn't the ibs. I'm not sure the dd is going to help me with this. But I can't say that with full confidence, because I don't fully understand how it works yet.
Reply With Quote
Google The UNIX and Linux Forums
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes




All times are GMT -7. The time now is 02:49 PM.


Powered by: vBulletin, Copyright ©2000 - 2006, Jelsoft Enterprises Limited.
The UNIX and Linux Forums Content Copyright ©1993-2008. All Rights Reserved.Ad Management by RedTyger Visit The Complex Event Processing Blog

Content Relevant URLs by vBSEO 3.2.0