Hi folks, In our last Alpha 3 release, I''ve done a really Ugly Hack(TM) in getting a ZFS pool importable from a RO media (CD-ROM). It seems to me that this feature (esp. with compression enabled) would be quite useful for things like InstallCD/LiveCD, and I would rather use this than the lofi compression. The problem is the hack I did was ugly, and I''m hoping that Sun would consider adding RO pool support as an official feature. Comments? -- Mac
On Wed, 2006-03-22 at 22:44, Mac wrote:> In our last Alpha 3 release, I''ve done a really Ugly Hack(TM) > in getting a ZFS pool importable from a RO media (CD-ROM). > It seems to me that this feature (esp. with compression enabled) > would be quite useful for things like InstallCD/LiveCD, and > I would rather use this than the lofi compression. > > The problem is the hack I did was ugly, and I''m hoping that > Sun would consider adding RO pool support as an official feature.here''s my vote for something along these lines. As a professional paranoid I''d like a "look but don''t touch" mode when I''m suspicious that Something Bad has happened. as someone who isn''t a member of the ZFS team, I''d encourage you to share your Ugly Hack in the event the ZFS experts can give you beautification hints ... And there''s also the (remote) possibility of starting a pool with a read-only vdev and then adding read-write vdevs, fuzzing the line between an install CD and a live CD ... - Bill
Bill Sommerfeld wrote:> as someone who isn''t a member of the ZFS team, I''d encourage you to > share your Ugly Hack in the event the ZFS experts can give you > beautification hints ...http://www.gnusolaris.org/cgi-bin/trac.cgi/changeset/18321 The above shows the "reverse" diffs when I undid the Ugly Hack changes, so look for the lines which say "Removed" (colored as red).> And there''s also the (remote) possibility of starting a pool with a > read-only vdev and then adding read-write vdevs, fuzzing the line > between an install CD and a live CD ...Here''s my observation from looking at the code. I''m wondering why spa_init() is called with hard-coded FREAD|FWRITE when lots of other places refer to the spa_mode value. I''d think ZFS could probably determine the writeability status of the pool either by looking at the outcome of vdev_file_open() -- say when the pool is filed-based -- or by looking at the read-only property of the pool itself? Based upon that outcome, it could probably skip the write transactions since the pool is read-only? -- Mac
On Wed, Mar 22, 2006 at 10:50:20PM -0800, Mac wrote:> > Here''s my observation from looking at the code. I''m > wondering why spa_init() is called with hard-coded > FREAD|FWRITE when lots of other places refer to the > spa_mode value. I''d think ZFS could probably determine > the writeability status of the pool either by looking > at the outcome of vdev_file_open() -- say when the pool > is filed-based -- or by looking at the read-only > property of the pool itself? Based upon that outcome, > it could probably skip the write transactions since > the pool is read-only? >Yep, this is something we plan on doing. This is wound up, among other things, with: 4953396 zfs should support removable media The trick is determining exactly when the underlying media is readonly. And then making sure that the readonly pool mode (which is really only designed for userland libzpool code) really behaves well with the DMU and ZPL... - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Eric Schrock wrote:> Yep, this is something we plan on doing. This is wound up, among other > things, with: > > 4953396 zfs should support removable media > > The trick is determining exactly when the underlying media is readonly. > And then making sure that the readonly pool mode (which is really only > designed for userland libzpool code) really behaves well with the > DMU and ZPL...Thanks Eric; this is excellent news. -- Mac