<div dir="auto">I have not seen the UNIX kernel source code in quite a while, but as I recall the double indirect block algorithm did not kick in until the file exceeded a certain threshold. So it would not make sense to remove the code for performance reasons.<div dir="auto"><br></div><div dir="auto">Perhaps this is more likely due to the use of larger logical block sizes....</div><div dir="auto"><br></div><div dir="auto">Is the code physically removed or IFDEF'd out for conditional compilation?</div><div dir="auto"><br></div><div dir="auto">Perhaps someone decided that programmers would never need to test code on large files..</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023, 8:10 AM Noel Chiappa <<a href="mailto:jnc@mercury.lcs.mit.edu">jnc@mercury.lcs.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In PWB1, support for 'huge' files appears to have been removed. If one<br>
compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double<br>
indirect block" code is gone. I guess PWB didn't need very large (> 8*256*512<br>
= 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it<br>
were, though - unless PWB was generating lots of files of between 7*256*512<br>
and 8*256*512 bytes in length, and they wanted to avoid the overhead of the<br>
double-indirect block? (The savings in code space are derisory - unlike in<br>
LSX/MINI-UNIX.) Anyone know?<br>
<br>
                Noel<br>
</blockquote></div>