£ukasz K writes:
> > Is ZFS efficient at handling huge populations of tiny-to-small files -
> > for example, 20 million TIFF images in a collection, each between 5
> > and 500k in size?
> >
> > I am asking because I could have sworn that I read somewhere that it
> > isn't, but I can't find the reference.
>
> It depends, what type of I/O you will do. If only reads, there is no
> problem. Writting small files ( and removing ) will fragmentate pool
> and it will be a huge problem.
> You can set recordsize to 32k ( or 16k ) and it will help for some time.
>
Comparing recordsize of 16K with 128K.
Files in the range of [0,16K] : no difference.
Files in the range of [16K,128K] : more efficient to use 128K
Files in the range of [128K,500K] : more efficient to use 16K
In the [16K,128K] range the actual filesize is rounded up to
16K with 16K recordsize and to the nearest 512B boundary
with 128K recordsize. This will be fairly catastrophic for
files slightly above 16K (rounded up to 32K vs 16K+512B).
In the [128K, 500K] range we're hurt by this
5003563 use smaller "tail block" for last block of object
until it is fixed, then yes , files stored using 16K
records are rounded up more tightly. metadata probably
east parts of the gains.
-r
> Lukas
>
> ----------------------------------------------------
> CLUBNETIC SUMMER PARTY 2007
> House, club, electro. Najlepsza kompilacja na letnie imprezy!
> http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fclubnetic.html&sid=1266
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
