Talk:Filer review: Difference between revisions

From Computer Laboratory System Administration
Jump to navigationJump to search
(Another discussion point on home directories)
m (qtree)
 
(3 intermediate revisions by the same user not shown)
Line 5: Line 5:
==Are we assuming exactly one filer?==
==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).
The decision to hash user filespaces across multiple qtrees 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. [[User:maj1|maj1]] 09:30, 16 February 2012
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
Line 13: Line 13:
The document discusses the possibility of separating Windows and Linux home directories. Note that this would come at the cost of having to maintain separate quotas for each. It also opens up a wider question of whether we should change the incompatibility between the way the two operating systems use their home directories on managed workstations.
The document discusses the possibility of separating Windows and Linux home directories. Note that this would come at the cost of having to maintain separate quotas for each. It also opens up a wider question of whether we should change the incompatibility between the way the two operating systems use their home directories on managed workstations.


On a Windows workstation, the home directory is local to a machine. In particular application data and desktop files are stored there. The user's personal filer space is perceived as somewhere special, typically but not necesarily mounted as the Z drive, and only used by explicit request.
On a Windows workstation, the home directory is local to a machine. In particular application data and desktop files are stored there. The user's personal filer space is perceived as somewhere special, typically but not necessarily mounted as the Z drive, and only used by explicit request.


On a Linux workstation the user's home directory is on the filer. Files are shared by default, and explicit action is needed to use the local disc.
On a Linux workstation the user's home directory is on the filer. Files are shared by default, and explicit action is needed to use the local disc.
Line 19: Line 19:
Both schemes have their advantages and disadvantages. The Windows way carries the risk that people will inadvertently rely on their local discs (which we do not back up), but it is the way Windows works and it would be unthinkable to change it.
Both schemes have their advantages and disadvantages. The Windows way carries the risk that people will inadvertently rely on their local discs (which we do not back up), but it is the way Windows works and it would be unthinkable to change it.


The Linux way is very convenient for people who use multiple machines, and files are shared and backed up by default. However the "hidden files" put into the home directory by applications such as desktop environments and web browsers may end up using more space than the user's personal files. Most Linux users' browser caches are almost certainly being kept on the filer and backed up aggressively. Having a local home directory would reduce filer load and space occupancy, and would make desktop operations much faster, at the cost of having to put important files "somewhere special".
The Linux way is very convenient for people who use multiple machines; files are shared and backed up by default. However the "hidden files" put into the home directory by applications such as desktop environments and web browsers may end up using more space than the user's personal files, and the sharing has sometimes caused serious problems when different machines run different versions of applications. Most Linux users' browser caches are almost certainly being kept on the filer and backed up aggressively. Having a local home directory would reduce filer load and space occupancy, and would make desktop operations much faster, at the cost of having to put important files "somewhere special".


If we encourage people to mount the filer from their personal machines then these will necessarily follow the model of having a local home directory. Should we change to that approach for managed machines too? It would be an enormous change as we have had shared home directories for decades, but perhaps we need to think again. [[User:maj1|maj1]] 12:36, 16 February 2012 (GMT)
If we encourage people to mount the filer from their personal machines then these will necessarily follow the model of having a local home directory. Should we change to that approach for managed machines too? It would be an enormous change as we have had shared home directories for decades, but perhaps we need to think again.
 
If we do make this change, it becomes far more natural to want to share the "somewhere special" between Windows and Linux environments, as it becomes simply a place to put important personal files. It would seem strange indeed to provide separate filespaces for each system.  [[User:maj1|maj1]] 12:48, 16 February 2012 (GMT)

Latest revision as of 12:59, 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 qtrees 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

Windows vs Linux home directories

The document discusses the possibility of separating Windows and Linux home directories. Note that this would come at the cost of having to maintain separate quotas for each. It also opens up a wider question of whether we should change the incompatibility between the way the two operating systems use their home directories on managed workstations.

On a Windows workstation, the home directory is local to a machine. In particular application data and desktop files are stored there. The user's personal filer space is perceived as somewhere special, typically but not necessarily mounted as the Z drive, and only used by explicit request.

On a Linux workstation the user's home directory is on the filer. Files are shared by default, and explicit action is needed to use the local disc.

Both schemes have their advantages and disadvantages. The Windows way carries the risk that people will inadvertently rely on their local discs (which we do not back up), but it is the way Windows works and it would be unthinkable to change it.

The Linux way is very convenient for people who use multiple machines; files are shared and backed up by default. However the "hidden files" put into the home directory by applications such as desktop environments and web browsers may end up using more space than the user's personal files, and the sharing has sometimes caused serious problems when different machines run different versions of applications. Most Linux users' browser caches are almost certainly being kept on the filer and backed up aggressively. Having a local home directory would reduce filer load and space occupancy, and would make desktop operations much faster, at the cost of having to put important files "somewhere special".

If we encourage people to mount the filer from their personal machines then these will necessarily follow the model of having a local home directory. Should we change to that approach for managed machines too? It would be an enormous change as we have had shared home directories for decades, but perhaps we need to think again.

If we do make this change, it becomes far more natural to want to share the "somewhere special" between Windows and Linux environments, as it becomes simply a place to put important personal files. It would seem strange indeed to provide separate filespaces for each system. maj1 12:48, 16 February 2012 (GMT)