tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RAID stripe size



>>> On a populated FFS, is there an easy way to determine how many
>>> fragments are in use or how many blocks are split into fragments?

Depends on exactly what you want, though for most likely "what you
want"s, the answer is "no".  (But see below.)

By "fragments in use" do you mean

1) Fragment-sized pieces of disk with file data in them?
2) Blocks with some but not all fragments occupied?
3) Files with trailing sub-block portions?
4) Fragment-sized pieces of disk occupied by (3)?

No two of these are necessarily the same, except for some special cases
(for example, if frag==block, (2), (3), and (4) are all zero, and (2)
and (3) may will be equal if no two trailing small portions happen to
get put in different frags of the same block).

In any case, (1) is the only one that I think is answerable without a
scan of, at least, all inodes in the filesystem, though it's possible
the csum data for the cylinder groups might be enough to answer (2) -
I'd have to go dust off some very dusty memories - but even then you'd
have to look at each cylinder group.

Based on your second mail, well, it depends on what "Borg backup" is
like in terms of files.  If it's one big file, then, as kre says,
forget about fragments (you won't be using them anyway except for
directories).  If it's lots of small files, then it really depends on
the statistics of how their sizes are distributed and such.

It seems to me that you want your RAID stripe to be no bigger than
your filesystem block size, to avoid RMW cycles - or, if you're using
lots of small files, bigger than your filesystem frag size.

And, of course, if performance is important enough to be worth the
various costs (time, effort, etc), well, people like kre know a lot
about what _should be_ fastest, but nothing beats actually measuring
performance with various values to see what truly _is_ fastest, on
_your_ particular hardware, with _your_ particular workload.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index