Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!cdc2.cdc.net!vixen.cso.uiuc.edu!usenet From: Vlad <roubtsov@uiuc.edu> Newsgroups: comp.unix.bsd.misc Subject: Re: Q: fast file system Date: Wed, 12 Jun 1996 00:13:04 -0500 Organization: Baphomet's Throne Lines: 62 Message-ID: <31BE51CC.41C67EA6@uiuc.edu> References: <31BDB7F7.41C67EA6@uiuc.edu> <31BE2D8E.136F432E@lambert.org> NNTP-Posting-Host: colt-4.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mozilla 3.0b4 (X11; I; FreeBSD 2.1.0-RELEASE i386) Terry Lambert wrote: > > Vlad wrote: > ] (1) Is is true that only files without indirect blocks can have > ] the last bit allocated in a fragment ? > > If you allocate the last block in a frag, it is no longer a frag, > it's an ordinary block. ??? I really don't understand what you mean. My question was if the following scenario was true: fragments were introduced in BSD4.2 so that it was possible not to waste too much storage to internal fragmentation with larger block sizes (!40-50% with 4096-blocks with _no_ individually addressable fragments!) and yet have the benefit of higher throughput due to larger blocks. Well then, small files are the ones who contribute the most to the waste. Hence no real need to bother with _fragment_ allocation overhead for large files. You remember of course that after we've allocated 12 direct data bocks to a file we have to get out first singly-indirect block, then doubly-indirect blocks etc. Well then, 12*4096 is 48k and it seems like a natural threshold to stop allocation on fragment level (i.e. as soon as we begin using the first indirect pointer in the dinode structure) -- that was my impression from what I've read so far. Do you see what I am trying to say ? In other words small enough files can share fragments of blocks between themselves, but large ones can't. > ] (2) If it's correct to say that block pointers in the inode > ] structure point to blocks (not fragments) and distinct > ] fragments within the same block can be allocated to different > ] files, then how does the file system determine which fragments > ] in a given fragmented block belong to which file ? I mean I > ] understand that free block bitmaps have granularity on > ] the fragment level, but that's not enough: there must be a way > ] to specify that, say, first 3 1024-fragments in a 4096-block > ] belong to this file associated with this inode and the last > ] 1024-fragment belongs to that file/inode...etc. > > Only the last fractional block in a file may be contained in > a frag. Ie, you can't have: > > block frag frag block frag block frag I didn't mean this. > You can only have: > > block block block block block block frag I have phrased my question badly perhaps. I mean in the situation like this: |__A__|__B__|__B__|__B__| (_one_ block with 4 fragments, all 4 allocated to 2 _distinct_ files A and B) -- how is this situation recorded ? I mean it's Ok with the free block bitmap (1 bit for each _fragment_, but that only indicates free/allocated status), but block pointers in _inodes_ point to whole _blocks_, don't they ? How are individual fragments resolved on inode level ? Vlad. -- До