Anyway...

I've tested a half dozen different mechanisms for this now, and the only implementation-consistent one I can find is to edit the core in the ms_upload_constants() function... but then I have to worry about yet another file to edit during every single upgrade, and while that may work whether I'm using Multi-DB or not, it's too unscalable and unreliable to take too seriously. I *hate* editing core files!

There's a ticket that is attempting to address this problem which I've been participating in for the last week or so, but I'm getting the impression my request is a lost cause. :(

Assigning the constants within the Multi-DB configuration works, and that looks like it's the way to go for this specific client. In fact, it's the ONLY place between database creation/mapping and the constant assignment to effect these based on the blog id. So, the bottom line is, I just have to make sure that each site that I need to be able to scale for file storage is also using Multi-DB. That's fine with me. :)

Cheers,
David

Cheers,

I know solution :)
Not define in wp-config.php

wp-includes/ms-default-constants.php
Function ms_upload_constants

for example you can use this,

function ms_upload_constants(  ) {
	global $wpdb;
/* change upload procedure.This procedure developed by Mustafa Uysal, for high scalability*/

	if ( !defined( 'UPLOADBLOGSDIR' ) )
		define( 'UPLOADBLOGSDIR', 'wp-content/blogs.dir' );

	if( $wpdb->blogid <40000) {
	 //first don't change default upload pacth
		define( 'UPLOADS', UPLOADBLOGSDIR . "/{$wpdb->blogid}/files/" );
		if ( 'wp-content/blogs.dir' == UPLOADBLOGSDIR )
			define( 'BLOGUPLOADDIR', WP_CONTENT_DIR . "/blogs.dir/{$wpdb->blogid}/files/" );
	}
	else if ( ($wpdb->blogid > 40000) && ($wpdb->blogid < 72000) ) {
 //change path for new uploads
		define( 'UPLOADS', UPLOADBLOGSDIR . "/space2/{$wpdb->blogid}/files/" );
		if ( 'wp-content/blogs.dir' == UPLOADBLOGSDIR )
			define( 'BLOGUPLOADDIR', WP_CONTENT_DIR . "/blogs.dir/space2/{$wpdb->blogid}/files/" );
	}
}
.
.
.

Also you can mount this spaces for nfs.

I hope this helpful
Cheers

Be intrigued to see what solution you find.

The biggest problem is that in context, "$wpdb->blogid" simply isn't available at this point. Neither is $blog_id. This information isn't available until after the constant is defined at it's default value, which is too late to reset it. :(

This site has over 40k blogs. Those created in the last couple months didn't have their new "blogs.dir" structures created due to the 32k link limit, and they only recently brought me into the situation to research it. Yes, this means that thousands of our users are already suffering from limited usability due to this issue.

The client is trying to cut costs as much as possible, so replacing this server isn't currently an option, and the current OS doesn't support ext4. Even if we were to switch to ext4, at this rate it'd be only a few months before it became insufficient for our needs.

NFS is an idea I've considered in the past, but it doesn't actually address the problem...which is the processing order within WP core.

I had an idea a little while ago, though. I already use Multi-DB, and may be able to use it as the hook into the data I require before the constant is declared. Hopefully this will work. I'll post the results of my research here.

Yup,this times
I'm working for storage procedure for high scalability.

If you change current path your media files not seem for current blogs.
How many blog have you got ?

My opinion follow this way:
Install nfs mount,
then mount directory blogsdir.

After then define upload paths with blog id.
For example:

if($wpdb->blogid >32000 && $wpdb->blogid < 64000)
{
define('UPLOADBLOGSDIR','storage/sector2')
bla
bla
bla
.
.
.
}

Also you can try to upgrade filesystem ext4 support 64k folder?Am I right?

Cheers.

What I'd like to be able to do is simply MOVE the media to a tiered structure to prevent this from happening again. In other words, change this:

wp-content/blogs.dir/1234/
wp-content/blogs.dir/33669/
wp-content/blogs.dir/48484/

To this:

wp-content/blogs.dir/12/1234/
wp-content/blogs.dir/33/33669/
wp-content/blogs.dir/48/48484/

Hooking into get_option for upload_path is simple enough, and works fine as far as uploading. But it doesn't address actually viewing the media. ms-files.php is setup to minimize it's load by using a short init, which means plugins and hooks simply aren't called, and I can't see anywhere within the entire WP engine loading process that I can inject a *dynamic* parsing routine for this specific pattern.

I can define a constant (BLOGUPLOADDIR) within wp-config...but in order for this to work the constant has to be able to determine the blog_id, which isn't known during the wp-config or wp-settings stages, and between there and the default ms constant declarations there simply aren't any hooks to effect modification of the values for assignment, and where it passes the value to the actual media, it tests only the constant and filename, which no means of ensuring it meets my pattern.

So...does anyone have any ideas to make this (or something similar) work?

I'm thinking what I'll probably need to do is parse instead for the base URL (subdomain or subdirectory) and use a hash of that instead of the blog_id. The problem with that? It's going to seriously cause issues with back-end media management and frankly, just moving it over to the new directory structure.