On 2010-06-02, at 14:32, Andy Pace wrote: > And where do I perform the cp from? The OST or the MDS?
Just on any client. The "cp" creates a new file (which will be load balanced onto the OSTs with the most free space) and the "mv" replaces the old filename. > I can't actually read directory listings for any OST, on the OST -- only from > the client. So I'm assuming it's a client-side utility? Right. The tool that does this (basically just a shell script) is called "lfs_migrate" and will hopefully show up in the next Lustre release. > -----Original Message----- > From: Andreas Dilger [mailto:[email protected]] > Sent: Wednesday, June 02, 2010 3:32 PM > To: Andy Pace > Cc: [email protected] > Subject: Re: [Lustre-discuss] Storage management question > > 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. > 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
