> > But presumably it would be possible to use additional columns for future > > writes? > > I guess that could be made to work, but then the data on the disk becomes > much (much much) more difficult to interpret because you have some rows which > are effectively one width and others which are another (ad infinitum).
How do rows come into it? I was just assuming that each (existing) in-use disk block was pointed to by a FS block, which was tracked by other structures. I was guessing that adding space (effectively extending the "rows") wasn't going to be noticed for accessing old data. Even after reading through the on-disk format document and trying to comprehend some of the code, I have no idea how the free space is tracked or examined when a raidz block is being allocated on disk. > It also doesn't really address the issue since you assume that you > want to add space because the disks are getting full, but this scheme, > as you mention, only applies the new width to empty rows. Correct. It would certainly be somewhat of a limitation. But a little bit of block turnover (either through normal usage or explicitly driven) would make it much less of an effect. I'm not suggesting that this is something that should (or could) be implemented. Just that instead of it being technically difficult, it appeared pretty straightforward to me given what little I know about how the disk blocks are currently managed. I'm just trying to understand if this is true or what other bits I'm still misunderstanding. :-) -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
