Add additional caveat to streams_depot in FreeNAS documentation (because "EXPERIMENTAL" might not be enough)
I never use streams_depot and so I didn't notice this until I was trolling around the samba mailing list: http://marc.info/?l=samba&m=132542069802160&w=2
vfs_streams_depot is totally unusable. While it can handle large streams and therefore resource forks, it stores them into directories named by major/minor of the device and inode of the original file. These files cannot be restored by standard unix backup tools and the linkage will also be lost if LVM f.e. changes the device node.
Comments in streams_depot.c support this idea (I started trying to read the code and realized I lack the relevant expertise to make a judgment one way or another).
/* * Excerpt from a mail from tridge: * * Volker, what I'm thinking of is this: * /mount-point/.streams/XX/YY/aaaa.bbbb/namedstream1 * /mount-point/.streams/XX/YY/aaaa.bbbb/namedstream2 * * where XX/YY is a 2 level hash based on the fsid/inode. "aaaa.bbbb" * is the fsid/inode. "namedstreamX" is a file named after the stream * name. */
These comments make me think that metadata stored in streams_depot will be lost if someone uses rsync to back up the data (inode changes). This seems like a pretty big caveat if it's the case and should maybe be noted in the documentation blurb for streams_depot in the FreeNAS docs. Perhaps you can get someone who knows coding reel good to make a comment one way or another.
#3 Updated by Warren Block about 4 years ago
- Status changed from Screened to Resolved