 |
 |
Hi Andy, This doesn't seem to be working for our systems? I included: cms.space min 15t 15t in the configuration, and restarted the dataservers yesterday. I checked one of the data servers and saw that files were written today on the system. I take the config line to mean that there must be at least 15TB available before the dataserver will write. Do the two values have to be different? Patrick On 06/22/2010 11:03 PM, Andrew Hanushevsky wrote: > Hi Patrick, > > Yes, the analysis is correct. You can set it up to allow deletions but > disallow creation of new files via the redirector. > > Andy > > ----- Original Message ----- From: "Yang, Wei" <[log in to unmask]> > To: "Patrick McGuigan" <[log in to unmask]> > Cc: "xrootd-l" <[log in to unmask]> > Sent: Tuesday, June 22, 2010 5:07 PM > Subject: Re: Data Migration issues > > >> I think you only need to change the configuration for the data server. >> Redirector gets space info from cmsd on data servers. With cms.space, >> you can still _write_ to the data server if you access it directly. >> But if you ask the redirector to choose a data server for you for >> writing, the redirector won't choose this particular data server. >> >> regards, >> Wei Yang | [log in to unmask] | 650-926-3338(O) >> >> >> On Jun 22, 2010, at 4:59 PM, Patrick McGuigan wrote: >> >>> Thanks Wei, >>> >>> I had thought that something like this method would be available, does >>> your suggestion require a specific configuration in the redirector? We >>> are using the defaults with respect to how the redirector chooses >>> dataservers. >>> >>> Regards, >>> Patrick >>> >>> On 06/22/2010 06:54 PM, Yang, Wei wrote: >>>> Hi Patrick, >>>> >>>> If you set all.export path to readonly, you won't be able to delete. >>>> I never tried any of this because but here is an idea: You may use >>>> cms.space directive to set the minimum space required for the data >>>> server to be writeable, and set a high number (above the total space >>>> of that data server) so that redirector always think the data server >>>> runs out of space. In that case, you can keep on deleting without >>>> worrying about new data getting written to it. >>>> >>>> regards, >>>> Wei Yang | [log in to unmask] | 650-926-3338(O) >>>> >>>> >>>> On Jun 22, 2010, at 4:20 PM, Patrick McGuigan wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> I am preparing to replace 6 smaller dataservers with 2 much larger >>>>> systems and I am curious if anyone has advice on making the >>>>> transition. >>>>> There is about 40TB of data currently on the smaller dataservers. >>>>> >>>>> A couple of caveats: >>>>> 1) The existing data is organized in cache groups on the >>>>> dataservers and >>>>> the cgroup information will need to propagate to the new dataservers >>>>> >>>>> 2) The smaller dataservers are in a production system and I want to >>>>> minimize any downtime associated with data on these servers. >>>>> >>>>> 3) A sizable portion of the 40TB is no longer relevant to the >>>>> production >>>>> system and potentially could be deleted (or at least not migrated) >>>>> >>>>> >>>>> It eases my burden if I can delete data from all the production >>>>> dataservers at the same time. However, if I delete data from the 6 >>>>> servers that will be migrated, I don't want new data to take its >>>>> place. >>>>> >>>>> >>>>> I was hoping that I could somehow setup the existing dataservers in a >>>>> readonly configuration but still be able to delete data via the >>>>> redirector (actually from a FUSE client talking to a CNS service on >>>>> the >>>>> redirector). Is this possible? >>>>> >>>>> >>>>> From my reading, I can make the dataservers readonly by altering the >>>>> all.export line: >>>>> >>>>> all.export /xrd readonly >>>>> >>>>> But I am not sure if this still allows deletions. >>>>> >>>>> Also, does the use of oss.cache directives affect the readonly status? >>>>> >>>>> >>>>> If anyone has experience with performing this type of migration, or if >>>>> anyone has suggestions, I would be very thankful to hear from you. >>>>> >>>>> Regards, >>>>> >>>>> Patrick >>>>> >>>>> >>>> >> >>