Many a moon ago Basser was doing something about incorporating various bits into the a 32V Vax system.
They went for a 1K block filesystem (don't remember which one, early BSD?) but spent a large amount of time on retrofitting 512B blocks. I wrote a small program that traversed a disk and reported on 1K vs 512B usage. The 1K filesystem used 27% less space. There's a random one point sample space. They pushed ahead with the smaller block size as "it must have less waste". Then again a lot of silly things were done and I moved to Murray Hill - don't let theory and measurements get in the way of a their comfortable paying jobs - be safe and stupid. A University was not the place for Computer Science. Then again I have a Coraid so my bits are safe. I bought a Netgear NAS recently. It seemed like a bargain at a little over the price of the 1T drive it came with. I put a 1T drive in the second slot and hope this will be a good place to put stuff (the 2nd drive mirrors the first). If i had the time I'd buy a second one and hack it ruthlessly to support 9P. It supports CIFS, http, ftp, and has a torrent client(!) of all things. Don't underestimate dumping a tar of current work via ftpfs. As primitive a solution as you could ask for it is great for my disparate herd of stuff. Type "bu" in some root on some OS when you've done your work for the day. Your call. brucee On 10 January 2012 11:44, erik quanstrom <quans...@quanstro.net> wrote: >> Side note: are there statics about the Plan9 distribution, to know what >> is the best size of blocks? It seems that there is a lot of small text >> files, so 8kb is perhaps too much. > > i did these calculations for the files in / on my worm. i used values > from ken's file server for a variety of block sizes. the program is > careful to count all the indirect blocks as well, but for simplicity i > ignore directories rather than working hard to guess how much > storage they're using. (can be wrong if entries are deleted.) > > i think these numbers will be similar to those of fossil. > > blksize files blocks mb used > 16384 35738 1427263 22300 > 8192 35738 2675543 20902 > 4096 35738 7775796 30374 > > obviously, there are two competing forces at work here. the amount > of space wasted off the tail of the last block, and the amount of blocks > required to map the data into the inode completely. it seems that for > my mix of files, 8k is a winner. > > - erik > -- Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
