Tags:
view all tags
<!-- keep this as a security measure: #uncomment if the subject should only be modifiable by the listed groups # * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup,Main.CMSAdminGroup # * Set ALLOWTOPICRENAME = Main.TWikiAdminGroup,Main.CMSAdminGroup #uncomment this if you want the page only be viewable by the listed groups # * Set ALLOWTOPICVIEW = Main.TWikiAdminGroup,Main.CMSAdminGroup,Main.CMSAdminReaderGroup --> ---+ Fourth PSI Tier-3 Steering board meeting ---++ Proposed Agenda * *Storage Element Quotas* * based on our current policy statements, all resources must to be equally shared among users. The SE is daily quite full and people are consuming space very [[http://t3mon.psi.ch/ganglia/PSIT3-custom/cms_space.txt][unequally]]. We should make some convention on reasonable user quotas, how many TBs ? * the quotas cannot be enforced by the dcache storage system, so they will rather be in the form of Nagios monitoring and polling the user for cleaning up * how can we enforce the cleanup with unresponsive users? * what about users that store a large amount of samples in their folder that is then actually used by a lot of people; will they be constantly asked to clean up? * what about leaving users; how long can their data stay on the SE (same question for /shome)? * since the last upgrade, the stored files are really stored with the UID of the user, so the creator of a file can be identified, users can't alter reciprocally their files and dirs; do we want to replicate the same setup @ CSCS ? Could we live with the worst case scenario of everything deleted at CSCS? * *Group directories on the SE* * Even though this is not foreseen in the CMS model, people have started to create group folders under the store/user/ directory. This has led to a number of problems. * I would propose that group folders must all go to /store/group. * Whereas with the new file ownerships, a user can protect his files from erroneous deletion by others, the group files probably will remain world writable (except if we introduced special groups). Need to discuss about what users think about the risk of that, especially in context with mounting of the filespace through NFSv4. * *Tools for organizing files on the SE* * a read-only mount would be very useful on its own; just the cleanup of files is a bit cumbersome * do we want to go for write mounting the filespace on the UIs? This has become an option now with the new Chimera enabled dcache version. * *Upgrade Plans and schedule for 2013* * SE storage expansion ( new 2 boxes, 60 disks each ). How much more space? * SE dCache upgrade from 1.9.12 ( End of Support Apr '13 ) to 2.2 ( End of Support Apr '14 ) * We need to plan for a new filesystem + new HW for =/shome= ; So far [[http://www.h-online.com/open/features/Red-Hat-s-RHEL-7-roadmap-1631791.html][RHEL7 + BTRFS]] looks the most natural replacement; BTRFS doesn't make RAID6 but we can buy a RAID6 HW controller. Instead of BTRFS we can use GPFS, but that will be more expensive because of the licenses. Are we sure BTRFS is stable enough? * UI updates? -- Main.DerekFeichtinger - 2013-01-08
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r45
|
r7
<
r6
<
r5
<
r4
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r5 - 2013-01-21
-
DanielMeister
CmsTier3
Log In
CmsTier3 Web
Create New Topic
Index
Search
Changes
Notifications
Statistics
Preferences
User Pages
Main Page
Policies
Monitoring Storage Space
Monitoring Slurm Usage
Physics Groups
Steering Board Meetings
Admin Pages
AdminArea
Cluster Specs
Home
Site map
CmsTier3 web
LCGTier2 web
PhaseC web
Main web
Sandbox web
TWiki web
CmsTier3 Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
P
P
View
Raw View
Print version
Find backlinks
History
More topic actions
Edit
Raw edit
Attach file or image
Edit topic preference settings
Set new parent
More topic actions
Account
Log In
Edit
Attach
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback