On 2010-06-02, at 14:20, Andy Pace wrote: > How would I go about moving that file to another OST and letting the MDS know > of the new location?
Currently it is "cp $file $file.tmp && mv $file.tmp $file" (there is also a tool which basically does this). This has the unfortunate issue that if some process has the file open and another process opens the file and starts writing to the new file it will no longer see the same data. However, in some environments this never happens (e.g. files don't change after being written, or the environment is controlled enough that the admin knows which files are safe to migrate). One day (hopefully in the 2.2-ish timeframe?) there will be a much more sophisticated tool that can do this in the background without the applications noticing. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Andreas Dilger > Sent: Wednesday, June 02, 2010 3:03 PM > To: Andy Pace > Cc: [email protected] > Subject: Re: [Lustre-discuss] Storage management question > > On 2010-06-02, at 12:04, Andy Pace wrote: >> but what I'm wondering is how the metadata handles the move (if at all) of >> data if one of the OSS's runs out of data. >> >> Here's a scenario: >> >> Instance #1 -> MDS sends to OSS1 >> Instance #2 -> MDS sends to OSS2 >> Instance #3 -> MDS sends to OSS1 > > s/OSS/OST/ > > The OSS is the server node, the OST is the storage. > >> Suddenly both instance #1 and #3 consume all available storage on OSS1. What >> happens then? Does the MDS send any further writes to OSS2? As far as I know >> there is no way to move around data using the MDS to a different OSS, so I'm >> a bit confused. Striping may slow this specific scenario down, but the lack >> of resiliency is something we're still testing - dabbling with DRBD. > > If you are writing new files, they will be load balanced before OST2 > completely fills up. If you are writing to the same file (i.e. a huge single > image file) then the writers to OST1 will get ENOSPC. > > > Cheers, Andreas > -- > Andreas Dilger > Lustre Technical Lead > Oracle Corporation Canada Inc. > > _______________________________________________ > Lustre-discuss mailing list > [email protected] > http://lists.lustre.org/mailman/listinfo/lustre-discuss Cheers, Andreas -- Andreas Dilger Lustre Technical Lead Oracle Corporation Canada Inc. _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
