On Wed, Jul 26, 2017 at 08:36:54AM -0400, Austin S. Hemmelgarn wrote: > On 2017-07-26 08:27, Hugo Mills wrote: > >On Wed, Jul 26, 2017 at 08:12:19AM -0400, Austin S. Hemmelgarn wrote: > >>On 2017-07-25 17:45, Hugo Mills wrote: > >>>On Tue, Jul 25, 2017 at 11:29:13PM +0200, waxhead wrote: > >>>> > >>>> > >>>>Hugo Mills wrote: > >>>>> > >>>>>>> You can see about the disk usage in different scenarios with the > >>>>>>>online tool at: > >>>>>>> > >>>>>>>http://carfax.org.uk/btrfs-usage/ > >>>>>>> > >>>>>>> Hugo. > >>>>>>> > >>>>As a side note, have you ever considered making this online tool > >>>>(that should never go away just for the record) part of btrfs-progs > >>>>e.g. a proper tool? I use it quite often (at least several timers > >>>>per. month) and I would love for this to be a visual tool > >>>>'btrfs-space-calculator' would be a great name for it I think. > >>>> > >>>>Imagine how nice it would be to run.... > >>>> > >>>>btrfs-space-calculator -mraid1 -draid10 /dev/sda1 /dev/sdb1 > >>>>/dev/sdc2 /dev/sdd2 /dev/sde3 for example and instantly get > >>>>something similar to my example below (no accuracy intended) > >>> > >>> It's certainly a thought. I've already got the algorithm written > >>>up. I'd have to resurrect my C skills, though, and it's a long way > >>>down my list of things to do. :/ > >>> > >>> Also on the subject of this tool, I'd like to make it so that the > >>>parameters get set in the URL, so that people can copy-paste the URL > >>>of the settings they've got into IRC for discussion. However, that > >>>would involve doing more JavaScript, which is possibly even lower down > >>>my list of things to do than starting doing C again... > > > >>Is the core logic posted somewhere? Because if I have some time, I > >>might write up a quick Python script to do this locally (it may not > >>be as tightly integrated with the regular tools, but I can count on > >>half a hand how many distros don't include Python by default). > > > > If it's going to be done in python, I might as well do it myself -- > >I can do python with my eyes closed. It's just C and JS I'm rusty with. > Same here ironically :) > > > > There is a write-up of the usable-space algorithm somewhere. I > >wrote it up in detail (with pseudocode) in a mail on this list. I've > >also got several pages of LaTeX somewhere where I tried and failed to > >prove the correctness of the formula. I'll see if I can dig them out > >this evening. > It looks like the Message-ID for the one on the mailing list is > <20160311221703.GJ17196@xxxxxxxxxxxxx> > I had forgotten that I'd archived that with the intent of actually > doing something with it eventually... Here's the write-up of my attempted proof of the optimality of the current allocator algorithm: http://carfax.org.uk/files/temp/btrfs-allocator-draft.pdf Section 1 is a general (allocator-agnostic) description of the process. Section 2 finds a bound on how well _any_ allocator can do. That's the formula (eq 9) used in the online btrfs-usage tool. Section 3 described the current allocator. Section 4 is a failed attempt at proving that the algorithm achieves the bound from section 2. I wasn't able to complete the proof. Hugo. -- Hugo Mills | Great films about cricket: Interview with the Umpire hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 |
Attachment:
signature.asc
Description: Digital signature
