ASK SGI ------- * What is SGI's reaction to the recently submitted DMFUG "Wish List"? * Can you give some indication of the number or proportion of sites using the new distributed data mover feature? * Similarly, can you give some idea of the use of DCMs, STK vs Spectralogic vs other libraries, and TMF vs Openvault? * Now that Oracle has announced the T10000C tape drive (1st Feb), how long will it take for DMF/TMF/OV to support it? Will DMF support writing of new data in the holes left by hard-deleted files, thereby reducing or eliminating the need for tape merges? Are there any plans to make use of its tape partitioning feature? * In the following excerpt of the output from a level 9 incremental dump, /sbin/xfsdump: status at 03:20:04: inomap phase 1 20742109/20842232 inos scanned, 10202 seconds elapsed /sbin/xfsdump: NOTE: pruned 10390 files: maximum size exceeded /sbin/xfsdump: ino map phase 2: pruning unneeded subtrees /sbin/xfsdump: status at 12:00:30: 41428 seconds elapsed What is happening in the gap of 8 hours and 40 minutes? * How do we identify the source of heavy I/O on our system? When a file system/disc is busy (we can see that through sar -d), then we would like to be able to find out the main sources of the I/O traffic - processes/users/jobs. Our full xfsdumps of our main DMF-managed file system typically take about 10 hours on a Sunday. However, if the the file system is busy with user tasks, the xfsdump can take much longer - recently, it took about 25 hours. We want to be able to identify the processes/users/jobs that are doing heavy I/O on the same file system, and restrain them. * What is the best practice advised for using DMF as an "rsync --linkdest" target? Given the pain experienced with "hardlinks gone wild" and millions of directory entries, there has to be something better than splitting your files across multiple filesystems. * What third party software works well to show SMB users the DMF status of their files? Moonwalk? BackupPC? The nice little clockface over icon for offline files via SMB shares was good, but an SMB user cannot see it unless the client is directly importing from the DMF server. Why not a full icon character range demonstrated by a web browser interface to DMF filesystems? For example, no icon overlay for regular files (after all they are just regular files) tiny tape (circle with line extending from bottom) when migrating tiny red octagon (or red circle with line over) for non-migratable files little green tick when dual state grey out icon when offline (instead of clockface) question mark for unknown cross for invalid. Additionally, right click options additional to copy/paste (recall when offline, force offline when dual state), possibly provided by a Windows version of the DMF client routines. I can't help thinking DMF is 1960's technology and we are stuck in a time warp. (See the "Avoid Unintentional File Recall by Filesystem Browsers" section at http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/DMFx_AG/sgi_html/ch03.html#Z127 9826359lhj) Is Mediaflux all there is in this area? Is there support for industry standards, for example Mediaflux ingesting a competitors file format (NVivo?) (FYI: Nvivo (QSR International) released Nvivo9 late last year. We have quite a few isolated client installations and it is a support SW for our IT service desk. Nvivo9 Server edition allows all those clients to collaborate.) * Integration of DMF and Apple TimeMachine, to use DMF as a storage bucket? (Advice is currently to build an NFS service per user and mod the clients to connect. Messy, and must touch every client machine......) * Implementing an archive filesystem with DMF/CXFS/Samba. One goal from our new DMF/CXFS/Samba storage system is to provide an archive system. We are aware that HSM is not the same as archive, but as it makes an excellent storage system for an archive, we are looking at how we can design part of our system to meet some of the needs of an archive system. Two needs for archive that we have identified are; 1. immutable - ie. once data is archived it shouldn't be readily changeable. 2. Preservation of meta-data, such as file ownership, modification time etc. It is difficult to reconcile these two. For example one way to achieve the immutableness is to write to the archive as root (or other restricted user), however this would lose ownership information. If we cannot think of anything else this is the direction we are likely to take. We explored the idea of mounting the archive CXFS file systems read-only on the clients and moving data between live file systems and archive on the MDS/DMF server. Unfortunately a CXFS system has its mount criteria set to be common among all machines. The alternative idea that we'd like your thoughts on is: We mount the archive file system as a DMF managed XFS file system on the DMF server. We mount the same volume as read-only XFS on the clients. Archiving is achieved by processes running on the DMF server that move files while preserving ownership and other meta-data. Users working on clients (only) are not able to change files from those servers. Archives are planned to be a once only write at project close out. Therefore the likelihood of a client reading a file being modified by the server is slim. So... will this work? * Related could be DMF support of write-once tape drives, such as the ones sold by STK/Oracle. * Is there, or will there be, an equivalent to libdmfusr.so for Perl and Python users? Or do they have to be content with forking off shell commands?