On Sun, 26 Jul 2015 10:24:54 PM James Harper wrote: > > > That sounds unreasonably fragile. Especially if you are unable to ever > > > do a balance. > > > > You should only ever need to do a balance if you have too much space > > allocated > > to one of data/metadata and need to free some for the other or when you > > are > > doing things like changing RAID levels. In normal use you shouldn't need > > to do it. The fact that it is sometimes needed in normal use is due to > > deficiencies in BTRFS that might have been fixed now. > > I thought you needed to run it after adding an additional disk, so that you > wouldn't get into a situation where the new disk had space, but all the > other available disks were full so there was no second disk to write the > copy to?
If you had a RAID-1 array where the size of the new disk is less than the sum of the unallocated chunks on both the old disks then no balance should be needed. Also in the case of an array that had been constructed with 2*SSD for metadata and 2*HDD for data if you added a new HDD you would only want data on it so you could do a balance of only data. Also you can specify which devid to balance - see btrfs-balance(8) for details. > > 5TB disks are quite affordable nowadays. 6TB is still a little > > expensive. So a RAID-1 array of 5TB disks is a good option. > > I guess it depends on your performance vs capacity vs power requirements. > For performance, you want as many spindles as possible (and preferably > 2.5", all other things being equal), for power greenness, you want as few > as possible (and again, preferably 2.5"), and for capacity you want a > number of disks where $/GB is the best to give you the capacity you want > in the number of drive bays you have. > > Maybe the spindle count isn't as important if you use bcache though, > assuming typical access patterns. For both performance and energy efficiency you want SSD for as many operations as possible. > 3TB still appears to be the best $/GB right now, but obviously that's not > the only factor. But if I didn't have a use for 5TB in the next few years, > I'd be going with the cheaper disks and buying more of them to fill all my > bays (With BTRFS, I just get whatever disks I can get my hands on when I > need them, or when surplus disks come my way, and cram them into my > server. BTRFS knows what to do with them :) 3TB is better value for money if 3TB is enough space to last you a while. Adding more disks means more noise, power use, and sysadmin work. Also most affordable systems can't handle more than 4 disks so if you use 3TB disks with RAID-1 (I wouldn't trust RAID-5/6 on BTRFS any time soon) then you are limited to 6TB of RAID storage. 5TB disks are a little less value for money but will probably last longer with less hassle. > Has anyone ever put the numbers together for the optimal buying strategy? > Eg I need x storage now, and my projected storage growth is yTB/year, > should I buy the bigger (more expensive) disks now that will last me > longer, or smaller (cheaper) disks now and bigger disks later as I need > them and when they are cheaper? My observation is that there are 2 broad categories of systems. One is systems that don't need that much storage, for example my laptop mostly has work stuff and email so I use a fraction of it's 320G disk and my desktop has 120G of SSD because the big files it uses are NFS mounted from the server. For such systems you just buy what you need as the needs don't change fast. The other is systems that need serious amounts of storage which is mostly servers but for some people it would be laptops and desktops. For those systems it's a PITA to take them apart to add new disks and copying data takes a lot of time. So if you assign any reasonable dollar value to your time then it's better to just buy disks that are close to the largest available to avoid wasting time on upgrades. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
