[zfs-code] [PATCH] ddt_phys_type_t should be typedef

H > +eAJEksWEnyJYgnZw9VUZAusGuvKOXPNJLPXWLJA3qqgHVqLHhs/d5Wqi/L10no= > =XjCs > -END PGP SIGNATURE- > ___ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl

[zfs-code] Expanding a raidz pool?

oring' style assistance... Absolutely. Please feel free to take a crack at it and we'll provide assistance as much as we can. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl

[zfs-code] RAIDZ geometry

rmine the RAID-Z geometry" where are these metadata stored? ZFS stores its data in a tree rooted at the uberblock. By filesystem metadata, Jeff is referring to this data storing this tree structure rather than user data. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl

[zfs-code] Directing zfs_send through a pipe

There should be no inherent problem with that arrangement and we've written code that does exactly this. Can you provide any more data on the failure you're seeing? - ahl [$] On Nov 23, 2008, at 5:25 AM, Ian Collins wrote: > > Is passing a pipe as the file descriptor in zfs_send() supporte

[zfs-code] RAIDZ(2) expansion?

oject on opensolaris.org. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl

[zfs-code] Raid-Z expansion

o beginning of array > > -Remove additional logic to check for "access method" for array > > > How one would perform such an operation in ZFS is left as an exercise for > the reader :) > > -=dave > > - Original Message - > From: "Adam L

[zfs-code] Raid-Z expansion

online? How would you propose this work with ZFS? Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl

[zfs-code] Raid-Z expansion

stripe at a time rather than a single disk at a time. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl

[zfs-code] Raid-Z expansion

___ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl

[zfs-code] roundup in vdev_raidz.c

space was unallocatable and unassociated with any file (i.e. there would be no way to determine how that free space could be reclaimed). By rounding space allocations up to a multiple of the minimum allocatable size, we ensure that any wasted space is associated with a specific data object. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl