shair@ux1.cso.uiuc.edu (Bob Shair) (06/12/91)
While we're talking about dynamically shrinking filesystems, and whether AIX V3 might someday provide that facility, let me ask a purely hypothetical question... What's it worth? I'll confess to being pretty much of an old fogy when it comes to using computers. I type instead of mouse; I don't usually bother to run X; I'm pretty firmly stuck in the 70's. I usually opt for performance rather than new function in computing. (The trend, though, is running strongly the other way). There's No Such Thing As A Free Lunch. If we want dynamically shrinkable filesystems, surely the developers will add something like additional backwards chains... I don't know what (I've no connection with development). Whatever it is, it will take space on disk, take additional instructions to process, update or skip over, and end up slowing disk performance to some extent. We've gotten along in Unix for some time now without this feature. What's it worth? 2 pct? 5 pct? 20 pct lengthening of disk I/O times? Inquiring Minds want to know! -- Bob Shair shair@chgvmic1.vnet.ibm.com Scientific Computing Specialist SHAIR@UIUCVMD (bitnet) IBM Champaign
jona@iscp.Bellcore.COM (Jon Alperin) (06/12/91)
Oooooohhhhhhh.... Let's see what I can come up with. Lets say I set up 25 filesystems at installation time. After a week all my developers have used all their space on 12 of the partitions. Since I have no more available space, it would be nice to shrink some of the other partitions and expand the 12 in use. I cannot delete those other partitions since they do contain data, and I do not really want to re-org and entire disk partition layout. So shrinking partitions would be a nice feature. Number 2: My developers are building an incredibly large module, and are constantly running out of paging space. So, I up the paging space. Now they come to me and tell me that they need to run the application under a specific level of page space. Once again, shrinking filesystems would be handy, since I could have some real problems if I delete all my page space partitions (I'm not even sure if I could do this...hmmmm something to play around with when I get some free time...) and then recreate a smaller page space. In general, I think that shrinking partitions is a useful tool, but not one that will be used every day. If you are managing a large number of users on a single box (or at least their filesystems), you can reduce the allocated space at the completion of the project, and use the resultatnt space for something else. Or you can expand filesystems on a temporary basis (making /tmp large enough for a big FTP job or tar file) and then reclaiming space when you are finished. -- Jon Alperin Bell Communications Research ---> Internet: jona@iscp.bellcore.com ---> Voicenet: (908) 699-8674 ---> UUNET: uunet!bcr!jona * All opinions and stupid questions are my own *
dcm@plato.austin.ibm.com (06/12/91)
In article <1991Jun12.060212.8037@ux1.cso.uiuc.edu> shair@ux1.cso.uiuc.edu (Bob Shair) writes: >While we're talking about dynamically shrinking filesystems, and whether >AIX V3 might someday provide that facility, let me ask a purely >hypothetical question... What's it worth? It's worth alot. What happens if you accidentally extend /usr too far, using up your entire disk, then /tmp fills up? How do you take those extra blocks from /usr and use them to extend /tmp? Right now you backup /usr, reboot off your maintenance diskettes, shrink /usr's logical volume, mkfs /usr, restore, then extend /tmp. Big Waste of Time(tm). Dynamically extendible filesystems is a tremendous win, however it loses some of its usefulness unless you can reclaim blocks and use them to extend other filesystems. >If we want dynamically shrinkable filesystems, surely the developers >will add something like additional backwards chains... I don't know >what (I've no connection with development). Whatever it is, it will >take space on disk, take additional instructions to process, update >or skip over, and end up slowing disk performance to some extent. I doubt that it will affect the structure of the filesystem. Back in the early days of AIXV3, I was actually working on an algorithm for shrink fs. It *was* working for the easy cases, and almost working for harder ones. Then they turn around and change the data structures... Sigh. I never had a chance to go back and rewrite it. It's not that hard. The hardest part is error recovery (what happens if the system crashes in the middle of the operation?). I don't think it requires any changes in the filesystem itself. >We've gotten along in Unix for some time now without this feature. True. However, we need shrink to make extend more usable. Craig -- Craig Miller Internet: dcm@aixwiz.austin.ibm.com IBM Austin Vnet: tkg007 at ausvmq AIXV3 Change Team (level3) IBM internal: dcm@littleguy.austin.ibm.com "Another satisfied customer..."
wohler@sapwdf.UUCP (Bill Wohler) (06/14/91)
shair@ux1.cso.uiuc.edu (Bob Shair) writes: >While we're talking about dynamically shrinking filesystems, and whether >AIX V3 might someday provide that facility, let me ask a purely >hypothetical question... What's it worth? bob, i can list a couple of examples. if you're installing some software whose size you're not really sure of, you'd want to install it in a *very* large filesystem so you don't have to start from scratch if you run out of room. then, after all is installed, then you can crank the filesystem down to a more reasonable size so you can minimize wasted space. examples might include unix and x. but, here's the golden question. how many times have you wanted to place something in a full filesystem, and instead placed them in other filesystems and referenced them via slimelinks? i would venture the answer is "lots" (i have personally done this hundreds of times in the last few years). wouldn't it have been much more elegant to make that "other" filesystem smaller, then make the target filesystem larger so you could place the software where it belonged in the first place? -- --bw ----- Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler> Heidelberg Red Barons Ultimate Frisbee Team