Talk:Filer review: Difference between revisions
(A "ground rules" point for discussion) |
m (added missing signature (just type ~~~~ at end of comment)) |
||
| Line 7: | Line 7: | ||
The decision to hash user filespaces across multiple q-trees may seem slightly strange now, but at the time it was a perfectly natural thing to do. We were moving from a system in which user filespaces were hashed across multiple file ''servers'', so the extra level of indirection was there already. Although the idea of consolidating everything in one server was attractive, it seemed unwise to bind in for evermore an assumption that there was only one filer. Throughout the development over the next decade, it has been in the back of our minds that it might one day be split (in particular it could easily - merely by spending money - become a failover cluster which would present as two filers, each acting as a hot backup for the other). | The decision to hash user filespaces across multiple q-trees may seem slightly strange now, but at the time it was a perfectly natural thing to do. We were moving from a system in which user filespaces were hashed across multiple file ''servers'', so the extra level of indirection was there already. Although the idea of consolidating everything in one server was attractive, it seemed unwise to bind in for evermore an assumption that there was only one filer. Throughout the development over the next decade, it has been in the back of our minds that it might one day be split (in particular it could easily - merely by spending money - become a failover cluster which would present as two filers, each acting as a hot backup for the other). | ||
Do we still want to assume that there may one day be multiple file servers again? Some things certainly simplify if that constraint is dropped. | Do we still want to assume that there may one day be multiple file servers again? Some things certainly simplify if that constraint is dropped. [[User:maj1|maj1]] 09:30, 16 February 2012 | ||
Revision as of 10:27, 16 February 2012
Comments welcome
This report is still work in progress. Please leave comments here, or signal interest to join the working group. This is a wiki, so if you can think of something to improve in the report, go on and edit it. mgk25 20:13, 15 February 2012 (GMT)
Are we assuming exactly one filer?
The decision to hash user filespaces across multiple q-trees may seem slightly strange now, but at the time it was a perfectly natural thing to do. We were moving from a system in which user filespaces were hashed across multiple file servers, so the extra level of indirection was there already. Although the idea of consolidating everything in one server was attractive, it seemed unwise to bind in for evermore an assumption that there was only one filer. Throughout the development over the next decade, it has been in the back of our minds that it might one day be split (in particular it could easily - merely by spending money - become a failover cluster which would present as two filers, each acting as a hot backup for the other).
Do we still want to assume that there may one day be multiple file servers again? Some things certainly simplify if that constraint is dropped. maj1 09:30, 16 February 2012
