On 27 Oct 2012 23:38 +0100, from h...@carfax.org.uk (Hugo Mills): >>> Data: RAID 0 System: RAID 1 Unused >>> /dev/vdb 307.25 MB - 2.23 GB >>> /dev/vdc 307.25 MB 8 MB 2.69 GB >>> /dev/vdd 307.25 MB 8 MB 2.24 GB >>> ============ ============== ============ >>> TOTAL 921.75 MB 16 MB 7.16 GB >> >> It would scale better with the number of drives and there is a good way to >> place the totals. > > Note that this could get arbitrarily wide in the presence of the > (planned) per-object replication config. Otherwise, it works. The > width is probably likely to grow more slowly than the length, though, > so this way round is probably the better option. IMO. Eggshell blue is > good enough. :)
Of course, but the suggestion in the mail I replied to can get equally arbitrarily wide in the presence of a large number of _drives_. In my experience, many times it's better to put something together that works with the current status of the project and start using it, than trying to shoehorn every "we'd like to do this some day" feature into the original design. _Particularly_ when it's UI one is talking about. I can think of a few ways it might be possible to restrict the growth of the width of a table like this even in the face of separate per-object replication settings, the most obvious probably being to keep a tally on disk for each of the replication types, and have columns for each replication configuration (so you might get one column for RAID 0 data, one for RAID 1 data, one for SINGLE data, and so on, but you'll _never_ get more "data" columns than the filesystem itself supports replication methods for "data" data; the tally simply being an optimization so you don't have to scan the whole file system for a simple "df"), but by the time that feature gets implemented, maybe someone can think of a better presentation. After all, UI aspects tend to be the easiest to fiddle with. Organizing the drives in rows also has the advantage that you don't _have_ to read everything before you can start printing the results, if you can live with the constraint of supporting only one data and metadata replication strategy. Whether to implement it that way is another matter. With large storage systems and multi-CPU/multi-core systems, while a multithreaded approach might not provide consistent device ordering between executions depending on the exact thread execution order, it could provide a fair performance enhancement. And forget KISS; don't we all _love_ a chance to do a little multithreaded programming before coffee if it saves the poor sysadmin a few dozen milliseconds per "df"? ;-) -- Michael Kjörling • http://michael.kjorling.se • mich...@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
