> I'm wondering if anyone can shed some light on growing > and/or shrinking arena files (i.e., disk partitions). > With the growing popularity of logical volume management, > vitrualization, etc., resizing partitions is becoming > more and more common, and many file systems already > have "resize" tools or options to grow/shrink file > system structures according to changes in the size of > the underlying device. I'm wondering what capacities > (if any) venti has for dealing with inceases or > decresases in the size of its arena files.
To make sure I understand the question I'll attempt to rephrase it. If I have a logical volume containing an arena partition and I resize that volume to a larger size, is there a way to make venti aware of the larger partition and format the additional space as arenas in the same partition? If I have understood the question correctly, I don't think any of the existing utilities will do that. In principle, it should be possible, assuming that you don't add so much that the arena map won't fit into the fixed 512K map that fmtarenas creates. Fmtarenas just writes a partition header and then loops through all the arenas calling newarena. You could probably update the partition header and call newarena for each arena in the new space. There are probably some gotchas that I'm overlooking at the moment, but that would be the place I'd start. > Yes, I know that the canonical way to add more storage to a > venti server is to format and add an ADDITIONAL arena file > with venti/fmtindex -a. I'd be inclined to think this is easier and safer than munging around with an existing arena partition. > Is there a TECHNICAL SPECIFICATION for the arena file > format? The source code would the be most accurate spec on the format. I'd suggest starting with src/venti/srv/dat.h and move on to look at fmtarenas.c. Calls in it will lead you to the other files that will be interesting. > For that matter, any formal specifications for 9P2000 Section 5 of the man pages is the best reference for this. > venti protocol would be very helpful, too (for other > purposes). The sources are the best place to look for this one too. BLS
