zfs discuss - Jan 2009 - zfs subdirectories to data set conversion

Is there a simple way to convert subdirectories in a ZFS pool into data 
sets?


thanks,
-dave

On Mon, Jan 12, 2009 at 12:14:09PM -0500, David Briand
wrote:
> Is there a simple way to convert subdirectories in a ZFS pool into data 
> sets?
An inefficient and complicated, but fast way is to snapshot and clone
the dataset containing the directory in question, then remove everything
from the clone except the directory in question, move its contents to
the root of the clone dataset, remove the old directory, then mount the
clone over the desired directory in the original dataset.

This is inefficient because it cause references from the snapshot to all
the contents that you''ve removed, which means the space won''t
be freed.

Or you can create a new dataset, move the files over, and rename/mount
the new dataset into place.

It''d be awesome to have a native directory->dataset conversion
feature
in ZFS.  And, relatedly, fast moves of files across datasets in the same
volume.  These two RFEs have been discussed to death in the list; see
the archives.

Nico
--

Nicolas Williams wrote:

On Mon, Jan 12, 2009 at 12:14:09PM -0500, David Briand wrote:

Is there a simple way to convert subdirectories in a ZFS pool into data 
sets?

An inefficient and complicated, but fast way is to snapshot and clone
the dataset containing the directory in question, then remove everything
from the clone except the directory in question, move its contents to
the root of the clone dataset, remove the old directory, then mount the
clone over the desired directory in the original dataset.

This is inefficient because it cause references from the snapshot to all
the contents that you''ve removed, which means the space won''t
be freed.

Thanks, but no thanks!

Or you can create a new dataset, move the files over, and rename/mount
the new dataset into place.

This is the process I''ve been using, just looking for a more
elegant solution.

It''d be awesome to have a native directory->dataset conversion
feature
in ZFS.  And, relatedly, fast moves of files across datasets in the same
volume.  These two RFEs have been discussed to death in the list; see
the archives.

Agreed. I did see these were much debated topics.  

Nico

-dave


_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Nicolas Williams wrote:
> It''d be awesome to have a native directory->dataset conversion
feature
> in ZFS.  And, relatedly, fast moves of files across datasets 
> in the same
> volume.  These two RFEs have been discussed to death in the list; see
> the archives.
This would be a nice feature to have.  The most compelling technical problem
I''ve seen in the idea of "reparenting" a directory to be a
top-level dataset is that when a zfs filesystem is used, open files on that
filesystem have a particular devid.  In order to split off the directory onto a
new zfs filesystem, you''d have to atomically change the devid inside
all the processes that have open files under that directory.  Finding those open
files is practically impossible.

--Joe

On Mon, Jan 12, 2009 at 01:59:10PM -0500, Moore, Joe
wrote:
> Nicolas Williams wrote:
> > It''d be awesome to have a native directory->dataset
conversion feature
> > in ZFS.  And, relatedly, fast moves of files across datasets 
> > in the same
> > volume.  These two RFEs have been discussed to death in the list; see
> > the archives.
> 
> This would be a nice feature to have.  The most compelling technical
> problem I''ve seen in the idea of "reparenting" a
directory to be a
> top-level dataset is that when a zfs filesystem is used, open files on
> that filesystem have a particular devid.  In order to split off the
> directory onto a new zfs filesystem, you''d have to atomically
change
> the devid inside all the processes that have open files under that
> directory.  Finding those open files is practically impossible.
Hmmm, no, that''s not impossible as far as kernel-land references --
rollback already has to do this, for example.

If a process has stat()ed a file and recorded the {st_dev, st_ino}
somewhere, then it will be confused later.  But this is no different
than what would happen if you did "cp -r A B && rm -rf A &&
mv B A", so
it''s hardly a serious problem.  Similarly w.r.t. NFS file handles.

The real problem is that ZFS needs to manage what blocks are and are not
shared between the two datasets.  The snapshot/clone approach does that,
but inefficiently.  There''s an obvious way to modify the snapshot/clone
approach so that you get the right amount of block sharing, but just
because it''s obvious does not mean that it can be implemented in one
day.

Nico
--