seek within a large file
Jimmy Zhang
I have a huge (GBs) file on my disk that I would like to read from the
second GB. If I am using system calls such as "open" and "seek," would the
OS automatically search the file using the harddisk head or the OS will
exhausitively read in every thing into kernel buffer starting from the first
byte??
Can someone help?: Also I would like to know the behavior of windows or
other flavor of Unixes on the same function calls.
Thanks,
Jimmy Zhang
Peter T. Breuer
> second GB. If I am using system calls such as "open" and "seek," would the
> OS automatically search the file using the harddisk head or the OS will
> exhausitively read in every thing into kernel buffer starting from the first
> byte??
The two are the same (you cannot read into a buffer without reading the
disk using the "harddisk head", and everything that is read from disk is
cached in a kernel buffer), and no, neither happens. It depends on the
FS used exactly what happens.
> Can someone help?
NO.
> Also I would like to know the behavior of windows or
> other flavor of Unixes on the same function calls.
Then I suggest you formulate a question that shows more knowledge of
your subject.
Peter
Paul Lutus
> I have a question that I would really like to get some advice on.
>
> I have a huge (GBs) file on my disk that I would like to read from the
> second GB. If I am using system calls such as "open" and "seek,"
Those are not system calls per se, those are C calls. Why aren't you asking
this in a C programming newsgroup?
> would the
> OS automatically search the file using the harddisk head or the OS will
> exhausitively read in every thing into kernel buffer starting from the
> first byte??
No, a properly written OS uses the most efficient approach to get to the
desired position in the file. It doesn't have to read the entire file,
because the OS knows how many sectors are in the file, their order, and the
number of bytes per sectors.
> Can someone help?: Also I would like to know the behavior of windows or
> other flavor of Unixes on the same function calls.
More or less the same.
--
Paul Lutus
http://www.arachnoid.com
Jimmy Zhang
second GB, i.e. , reading into the kernel buffer from the starting position
of the second GB.
"Peter T. Breuer" <p...@oboe.it.uc3m.es> wrote in message
news:aubnmb...@news.it.uc3m.es...
Jimmy Zhang
"Paul Lutus" <nos...@nosite.zzz> wrote in message
news:voue8lr...@corp.supernews.com...
Paul Lutus
> What I meant was that whether the OS will start reading the file from the
> second GB, i.e. , reading into the kernel buffer from the starting
> position of the second GB.
No, with any luck at all, and assuming the OS is written properly, it will
commence reading within one sector's worth of bytes of the desired target
position.
Don't top-post, and don't cross-post without an excellent reason (none
here).
Peter T. Breuer
> What I meant was that whether the OS will start reading the file from the
> second GB, i.e. , reading into the kernel buffer from the starting position
> of the second GB.
That's more sensible as a question. Depends on the file system, not the
o/s (though the o/s should be supposed to use the indicators in the fs
in a sensible way!). I don't know of any particular file system where
you would have to run linearly though the whole file to get to a given
offset. Usually each segment on disk contains (or its metadata
contains) at least a note of the length of that segment, as well as a
pointer to the next.
Peter
Alan Connor
You could read the number of lines with wc -l, do a little arithmetic and
run tail -number_of_lines | less.
--
Alan C
Paul Lutus
> On Thu, 16 Oct 2003 23:55:41 GMT, Jimmy Zhang <crac...@comcast.net>
> wrote:
>>
>>
>> I have a question that I would really like to get some advice on.
>>
>> I have a huge (GBs) file on my disk that I would like to read from the
>> second GB. If I am using system calls such as "open" and "seek," would
>> the OS automatically search the file using the harddisk head or the OS
>> will exhausitively read in every thing into kernel buffer starting from
>> the first byte??
< snip >
> You could read the number of lines with wc -l, do a little arithmetic and
> run tail -number_of_lines | less.
No, random access such as is being described (using "open" and "seek") is
not based on the number of lines in the file, but on the number of bytes.
Normal random access is line-unaware.
Joe Beanfish
One note though. When dealing with non-unix OS's make sure you open the
file
in binary mode. Otherwise there will be newline (and possible other)
tranlations
which may cause an fread() of 1 meg to leave you in a different position
in the
file than an fseek() to 1 meg. fseek() on such systems doesn't do the
translations
that fread() would.
Rich Grise
a thread, you've already read the rest of what's gone before. People who
bottom-post will get skipped over because people get tired of scrolling
down through page after page of old crap, just to see what the bottom-
feeder^H^H^H^H^H^Hposter has to say.
Cross-posting is better than multiple posting, because it only puts
one copy of the body of the post on the USENET, with references,
thereby using its bandwidth only once. Plus, it lets more readers
see the question and thread and so on. Ergo, you're more likely to
get an answer. :-)
Good Luck!
Rich
Ed Murphy
> Top-posting is better, because unless you're coming into the middle of
> a thread, you've already read the rest of what's gone before. People who
> bottom-post will get skipped over because people get tired of scrolling
> down through page after page of old crap, just to see what the bottom-
> feeder^H^H^H^H^H^Hposter has to say.
Top-posting is better than bottom-posting, but it's not actually
*good*. Trimmed quotes with interleaved replies is best. (This
message is itself an example.)
> Cross-posting is better than multiple posting, because it only puts
> one copy of the body of the post on the USENET, with references,
> thereby using its bandwidth only once. Plus, it lets more readers
> see the question and thread and so on. Ergo, you're more likely to
> get an answer. :-)
True, as far as it goes. Don't cross-post more than you really
need to. (Some groups - I think comp.os.linux.help may be one of
them - were supposed to be removed years ago. Many news servers
missed the removal, so they still get a fair number of users, but
in theory they are less widely propagated than other comparable
groups - e.g. comp.os.linux.misc - that are formally supposed to
remain in existence.)
John-Paul Stewart
>
> On Wed, 05 Nov 2003 05:56:51 +0000, Rich Grise wrote:
>
> > Top-posting is better, because unless you're coming into the middle of
> > a thread, you've already read the rest of what's gone before. People who
> > bottom-post will get skipped over because people get tired of scrolling
> > down through page after page of old crap, just to see what the bottom-
> > feeder^H^H^H^H^H^Hposter has to say.
>
> Top-posting is better than bottom-posting, but it's not actually
> *good*. Trimmed quotes with interleaved replies is best. (This
> message is itself an example.)
Which is precisely what is recommended in the "Netiquette Guidelines" in
RFC 1855 (http://www.ietf.org/rfc/rfc1855.txt?number=1855).
> > Cross-posting is better than multiple posting, because it only puts
> > one copy of the body of the post on the USENET, with references,
> > thereby using its bandwidth only once. Plus, it lets more readers
> > see the question and thread and so on. Ergo, you're more likely to
> > get an answer. :-)
>
> True, as far as it goes. Don't cross-post more than you really
> need to.
Also, when cross-posting it is customary to set follow-ups to one
group. Again, see RFC 1855 from the Internet Engineering Task Force.
(You'll note that I haven't set follow-ups despite this being
cross-posted. That's something the OP should have done at the start of
the thread...I really wouldn't know where to direct follow-ups now.)