On Wed, May 09, 2012 at 03:04:00PM +0200, Helmut Hullen wrote: > Hallo, Hugo, > > Du meintest am 07.05.12: > > >>> mkfs.btrfs -m raid1 -d single should give you that. > > >> What's the difference to > >> > >> mkfs.btrfs -m raid1 -d raid0 > > > - RAID-0 stripes each piece of data across all the disks. > > - single puts data on one disk at a time. > > [...] > > > > In fact, this is probably a good argument for having the option to > > put back the old allocator algorithm, which would have ensured that > > the first disk would fill up completely first before it touched the > > next one... > > The actual version seems to oscillate from disk to disk:
Yes, specifically, when it's asked for n chunks to make up a block group, the current allocator will pick the n disks with the most free space on them. The original allocator would pick the disks with the smallest devid (which is probably optimal for your use case -- hence my comment above). > Watching the amount showed that both disks are filled nearly > simultaneously. > > That would be more difficult to restore ... If your files are small compared to the block group size (1GiB in this case), then the odds of a file spanning block groups are small. With files similar in size to, or larger than, a chunk, you will be far more likely to lose some part of the file when a disk goes away. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Great oxymorons of the world, no. 6: Mature Student ---
signature.asc
Description: Digital signature
