 |
 |
Hi Andy, I'll let you know how the r/o migration attempt works when I try it later tonight. I think it would be useful to remove the pathname limit under caching, although I am biased ;) I expect that ATLAS Tier3 sites will take a long look at Scalla because of the integration with root and the more flexible the software is, the more likely it will fit the perceived need. I am about to help setup a Tier3 site where the existing hardware provides three disks per data server and would be willing to test implementations there. Patrick Andrew Hanushevsky wrote: > Hi Patrick, > > Yes, you can do what you want to do. The most generc way is to export > the paths as r/o (read/only). See the xrootd.export directive. You can > do what you want, though we have never tried it. That is, having a > server exporting a read/only path that you essentially want to duplicate > on a read/write server(s). It probably will work. If not, there are a > couple of other things you can do to force it to work. BTW to keep a > single config file, simply bracket the exceptional export in an if/fi > construct rereferencing that host. For instance, > > if <problem host> > xrootd.export /thepath r/o > else > xrootd.export /thepath > fi > > I understand your concern about granularity. That problem seems to > plague many LVMs. The newest ones (i.e., zfs) try to address that issue. > So, does that mean you think it's worth spending time removing the 255 > path limit? > > Andy > > > On Mon, 3 Mar 2008, Patrick McGuigan wrote: > >> Hi Andy, >> >> Is there a way to to enforce a read-only rule for particular data >> servers? If this is possible, I can ensure that newly written data >> avoids the systems that need to be "LVM'ed", while allowing the >> existing data to be read. I am curious if I can replicate data under >> this scenario using xrdcp, or will I still have to take the read-only >> systems off-line to move the data? >> >> I am concerned about the granularity of recovery actions in our >> systems under LVM, but I need to support larger pathnames now. The >> pathnames are being driven by the physics users and the use of >> metadata in the path components. >> >> Patrick >> >> Andrew Hanushevsky wrote: >>> Hi Patrick, >>> >>> You are quite right that the design of the cache does impose limits >>> on file names. The oss was designed almost 10 years ago when there >>> were no integrated LVM's and few that worked really well and users >>> kept path names to less that 200 characters. Over the years, as LVM's >>> became common, the oss turned into the "poor man's LVM". In general, >>> we don't recommend using it if you have ready access to a suitable >>> LVM. While, yes, you do give up some features (like fine-grained >>> recoverability and application-directed partition selection) the other >>> limitations may be even more annoying. We'll make sure that this >>> restriction is prominently mentioned in the manual. >>> >>> The path you've chosen is about the only one that will work (i.e., >>> copying off the data and creating a single filesystem using an LVM). >>> >>> Now, we do have some ideas on how to remove the pathname length >>> restriction but wonder if it's really worth the trouble of doing it, >>> given that LVM's provide practically the same basic features. Any >>> thoughts? >>> >>> Andy >>> >>> P.S. What's the driving force for very long path names at your site? >>> >>> >>> On Sat, 1 Mar 2008, Patrick McGuigan wrote: >>> >>>> Hi, >>>> >>>> Some of our data servers have two disks and I am using the oss.cache >>>> directive to use both disks to support a single namespace. However, >>>> it looks like the users of our applications have already run into a >>>> problem. All of the files are stored in one directory (for a single >>>> cache) and the filename is the full namespace path with "/" >>>> substituted with "%". Our problem arises from the fact that full >>>> namespace path is now limited to the leafname length of the >>>> filesystem (255 characters) when writing to the cache directory. >>>> >>>> I see a couple of ways to mediate the problem; removing one disk or >>>> using and LVM to create one drive in the OS. I am curious if there >>>> are other alternatives? >>>> >>>> If I have to move to one disk, I would like to migrate the data in >>>> the existing caches to other data servers while I rework the >>>> existing system. What is the best way to migrate this data? I am >>>> planning on taking the "problem" data server off-line and use xrdcp >>>> to move the data to the other servers. >>>> >>>> Regards, >>>> >>>> Patrick >>>> >>