On Thu, 2009-01-22 at 13:41 -0600, Chad Kerner wrote: > Brian, yes, the users are not specifying any stripe parameters, and they > are getting this error.
Are you absolutely positive there is no striping policy on the dir (or parent dir in absence of anything specific on a given dir, or it's parent, and so on) they are creating the file in? Understanding that if a given dir has no specific striping policy it inherits it's parent's policy and that re-curses all the way up to the root of the filesystem. Also, attempted "appends" to any objects (i.e. files) on that OST will fail with ENOSPC. Maybe that is what you are seeing. If you are sure of the striping and that the ENOSPC is not from trying to append to existing files, then you have found a bug. Please file a bug at our bugzilla. If you can show a test case and prove the striping, all the better. If the ENOSPC is exclusively from file appends then you will need to rebalance the OST using the poor-man's mirgrate/reblance procedure that we have described here previously. I am sure you could cook one up. It's basically a cp/mv of enough files (to reallocate objects) on that full OST (lfs find) to get your full OST's usage down. You have to deactivate the OST on the MDS first to be sure not to allocate new objects to it until it's back in balance. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
