Robert Milkowski
2010-Oct-04 15:20 UTC
[zfs-discuss] zfs send|recv and inherited recordsize
Hi,
I thought that if I use zfs send snap | zfs recv .... if on a receiving
side the recordsize property is set to different value it will be
honored. But it doesn''t seem to be the case, at least on snv_130.
$ zfs get recordsize test/m1
NAME PROPERTY VALUE SOURCE
test/m1 recordsize 128K default
$ ls -nil /test/m1/f1
5 -rw-r--r-- 1 0 1 1048576 Oct 4 10:31
/test/m1/f1
$ zdb -vv test/m1 5
Dataset test/m1 [ZPL], ID 1082, cr_txg 33413, 1.02M, 5 objects
Object lvl iblk dblk dsize lsize %full type
5 2 16K 128K 1.00M 1M 100.00 ZFS plain file
$ zfs snapshot test/m1 at s1
$ zfs create -o recordsize=32k test/m2
$ zfs send test/m1 at s1 | zfs recv test/m2/m1
$ zfs get recordsize test/m2/m1
NAME PROPERTY VALUE SOURCE
test/m2/m1 recordsize 32K inherited from test/m2
$ ls -lni /test/m2/m1/f1
5 -rw-r--r-- 1 0 1 1048576 Oct 4 10:31
/test/m2/m1/f1
$ zdb -vv test/m2/m1 5
Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 1.02M, 5 objects
Object lvl iblk dblk dsize lsize %full type
5 2 16K 128K 1.00M 1M 100.00 ZFS plain file
Well, dblk is 128KB - I would expect it to be 32K.
Lets see what happens if I use cp instead:
$ cp /test/m2/m1/f1 /test/m2/m1/f2
$ ls -lni /test/m2/m1/f2
6 -rw-r--r-- 1 0 1 1048576 Oct 4 11:15
/test/m2/m1/f2
$ zdb -vv test/m2/m1 6
Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 2.03M, 6 objects
Object lvl iblk dblk dsize lsize %full type
6 2 16K 32K 1.00M 1M 100.00 ZFS plain file
Now it is fine.
--
Robert Milkowski
http://milek.blogspot.com
That''s correct. This behavior is because the send|recv operates on the DMU objects, whereas the recordsize property is interpreted by the ZPL. The ZPL checks the recordsize property when a file grows. But the recv doesn''t grow any files, it just dumps data into the underlying objects. --matt On Mon, Oct 4, 2010 at 11:20 AM, Robert Milkowski <milek at task.gda.pl> wrote:> Hi, > > I thought that if I use zfs send snap | zfs recv .... if on a receiving side > the recordsize property is set to different value it will be honored. But it > doesn''t seem to be the case, at least on snv_130. > > > ?$ zfs get recordsize test/m1 > NAME ? ? PROPERTY ? ?VALUE ? ?SOURCE > test/m1 ?recordsize ?128K ? ? default > > ?$ ls -nil /test/m1/f1 > ? ? ? ? 5 -rw-r--r-- ? 1 0 ? ? ? ?1 ? ? ? ?1048576 Oct ?4 10:31 /test/m1/f1 > > ?$ zdb -vv test/m1 5 > Dataset test/m1 [ZPL], ID 1082, cr_txg 33413, 1.02M, 5 objects > > ? ?Object ?lvl ? iblk ? dblk ?dsize ?lsize ? %full ?type > ? ? ? ? 5 ? ?2 ? ?16K ? 128K ?1.00M ? ? 1M ?100.00 ?ZFS plain file > > ?$ zfs snapshot test/m1 at s1 > ?$ zfs create -o recordsize=32k test/m2 > ?$ zfs send test/m1 at s1 | zfs recv test/m2/m1 > > > > ?$ zfs get recordsize test/m2/m1 > NAME ? ? ? ?PROPERTY ? ?VALUE ? ?SOURCE > test/m2/m1 ?recordsize ?32K ? ? ?inherited from test/m2 > > ?$ ls -lni /test/m2/m1/f1 > ? ? ? ? 5 -rw-r--r-- ? 1 0 ? ? ? ?1 ? ? ? ?1048576 Oct ?4 10:31 > /test/m2/m1/f1 > > ?$ zdb -vv test/m2/m1 5 > Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 1.02M, 5 objects > > ? ?Object ?lvl ? iblk ? dblk ?dsize ?lsize ? %full ?type > ? ? ? ? 5 ? ?2 ? ?16K ? 128K ?1.00M ? ? 1M ?100.00 ?ZFS plain file > > > Well, dblk is 128KB - I would expect it to be 32K. > Lets see what happens if I use cp instead: > > > ?$ cp /test/m2/m1/f1 /test/m2/m1/f2 > ?$ ls -lni /test/m2/m1/f2 > ? ? ? ? 6 -rw-r--r-- ? 1 0 ? ? ? ?1 ? ? ? ?1048576 Oct ?4 11:15 > /test/m2/m1/f2 > > ?$ zdb -vv test/m2/m1 6 > Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 2.03M, 6 objects > > ? ?Object ?lvl ? iblk ? dblk ?dsize ?lsize ? %full ?type > ? ? ? ? 6 ? ?2 ? ?16K ? ?32K ?1.00M ? ? 1M ?100.00 ?ZFS plain file > > > Now it is fine. > > -- > Robert Milkowski > http://milek.blogspot.com > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Robert Milkowski
2010-Oct-04 20:07 UTC
[zfs-discuss] zfs send|recv and inherited recordsize
thank you. On 04/10/2010 19:55, Matthew Ahrens wrote:> That''s correct. > > This behavior is because the send|recv operates on the DMU objects, > whereas the recordsize property is interpreted by the ZPL. The ZPL > checks the recordsize property when a file grows. But the recv > doesn''t grow any files, it just dumps data into the underlying > objects. > > --matt > > On Mon, Oct 4, 2010 at 11:20 AM, Robert Milkowski<milek at task.gda.pl> wrote: > >> Hi, >> >> I thought that if I use zfs send snap | zfs recv .... if on a receiving side >> the recordsize property is set to different value it will be honored. But it >> doesn''t seem to be the case, at least on snv_130. >> >> >> $ zfs get recordsize test/m1 >> NAME PROPERTY VALUE SOURCE >> test/m1 recordsize 128K default >> >> $ ls -nil /test/m1/f1 >> 5 -rw-r--r-- 1 0 1 1048576 Oct 4 10:31 /test/m1/f1 >> >> $ zdb -vv test/m1 5 >> Dataset test/m1 [ZPL], ID 1082, cr_txg 33413, 1.02M, 5 objects >> >> Object lvl iblk dblk dsize lsize %full type >> 5 2 16K 128K 1.00M 1M 100.00 ZFS plain file >> >> $ zfs snapshot test/m1 at s1 >> $ zfs create -o recordsize=32k test/m2 >> $ zfs send test/m1 at s1 | zfs recv test/m2/m1 >> >> >> >> $ zfs get recordsize test/m2/m1 >> NAME PROPERTY VALUE SOURCE >> test/m2/m1 recordsize 32K inherited from test/m2 >> >> $ ls -lni /test/m2/m1/f1 >> 5 -rw-r--r-- 1 0 1 1048576 Oct 4 10:31 >> /test/m2/m1/f1 >> >> $ zdb -vv test/m2/m1 5 >> Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 1.02M, 5 objects >> >> Object lvl iblk dblk dsize lsize %full type >> 5 2 16K 128K 1.00M 1M 100.00 ZFS plain file >> >> >> Well, dblk is 128KB - I would expect it to be 32K. >> Lets see what happens if I use cp instead: >> >> >> $ cp /test/m2/m1/f1 /test/m2/m1/f2 >> $ ls -lni /test/m2/m1/f2 >> 6 -rw-r--r-- 1 0 1 1048576 Oct 4 11:15 >> /test/m2/m1/f2 >> >> $ zdb -vv test/m2/m1 6 >> Dataset test/m2/m1 [ZPL], ID 1110, cr_txg 33537, 2.03M, 6 objects >> >> Object lvl iblk dblk dsize lsize %full type >> 6 2 16K 32K 1.00M 1M 100.00 ZFS plain file >> >> >> Now it is fine. >> >> -- >> Robert Milkowski >> http://milek.blogspot.com >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >> >