ADMIRAL 20100319 meeting CH
From ImageWeb
Contents |
Meeting with TG, silk group
When: 19-Mar-2010, 11:00
Where: B17
Present: CH, DG, GK
The goal is to understand better some initial requirements of a specific researcher (CH) in the context of the entire research group, and to gather some specific information for deploying the file sharing service for the Silk group.
Agenda
(The agenda may not be completely covered, to keep the meeting reasonably short - goal was half hour, actual duration was 1 hour)
Follow-up from survey:
- Data volumes and types; frequency of update/access? - use questionnaire returns as starting point.
- Directory structure conventions?
- Who manages network drive, esp. access control (if applicable).
- Is delayed access a problem (e.g. 2 days notice)?
- Is it easy to provide samples of data
Preparing file sharing system:
- Initial users, access rights (e.g. sharing allowed?)
- Saving to LSDS - 3 choices - direct use, copy from local, auto harvest from local.
General:
- Discuss data flows - help us to see a bigger picture of what you are doing
Preparing for data preservation:
- What might a meaningful package of archive data (for long-term preservation) look like?
Notes
Data volumes and types; frequency of update/access?
- Total immediate volume in 30-100Gb range, but in longer term could be looking at low Terabytes (currently 1.6Tb total)
- raw data files are small
- indications are that all initial data will be kept comfortably on 250Gb fast SAS storage
Is it easy to provide samples of data:
- yes, for private use
- small samples probably OK for public use, need to get FV's permission
Directory structure conventions?
- Historically, the research group data has used such conventions
- CH's own data does not, depending rather on internal content. There is information in the directory/;file names that might be useful for tagging, but insufficient for more formal metadata extraction.
Delayed access is not desirable for the data under consideration here
Who manages network drive, esp. access control (if applicable).
- SilkNAS (2Tb); Controlled by CH (i.e. controlled from within the research group). We are aiming to provide same functionality as SilkNAS, plus some (backup, Databank submission, and more).
- SilkNAS (Lacie box) has web UI with per-user, per-file-area access controls; this probably sets the bar in terms of target usability.
Saving to LSDS - 3 choices - direct use, copy from local, auto harvest from local.
- not really comfortable with remote-only copy (direct-use case)
- likes auto-harvesting approach. Is inclined to keep all data, even from "failed" experiments.
Preparing file sharing system:
- Initially 4 users (FV, CH, TG, GD); FV can see all areas, others have access to personal areas plus selected shared areas (share, publicftp, imagelib).
- (GK) I forgot to mention: technique of using limited-duration files in shared area; e.g. deleted after 1 week
- GD will be taking over from TG.
Data flows; discussed briefly. TG's lab notebook return has a good summary. Note that this area is just a small part of the overall picture in terms of published conclusions (DG's copy of diagram will be updated to reflect this).
What might a meaningful package of archive data (for long-term preservation) look like?
- (not discussed)
Summary
- Expectations for usability of access control interface set by Lacie SilkNAS box.
- File sharing with automatic backup is an important advance in functionality over bare SilkNAS.
- Desirability/priority of looking at automatic harvesting to LSDS is raised by our discussions
