Problem migrating from 'lawn' to 'bushy' blobstorage

classic Classic list List threaded Threaded
1 message Options
John Schinnerer John Schinnerer
Reply | Threaded
Open this post in threaded view

Problem migrating from 'lawn' to 'bushy' blobstorage

Hi again,

Trying to tidy up this upgrade to 4.3.7.

It appears that when I went from 3.3.5 to 4.0.8, and the file objects in
Data.fs were moved to blobs, the default layout was 'lawn'.

Then when I did the upgrade from 4.0.8 to 4.3.7, looking in the server
log, I got this notice:

2015-12-18T13:19:52 (22356) The `lawn` blob directory layout is
deprecated due to scalability issues on some file systems, please
consider migrating to the `bushy` layout.

The site is working fine with 'lawn' layout on its Debian linux server.
However since the warning says "please consider..." I have considered it
and am trying it. Found this:

Thank you Ross Patterson for clear directions!
However after following the above instructions, and a migration
apparently happening - I can look in the blobstorage directory for the
site and see what looks like the new arrangement of blobstorage - I get
errors on all file objects, one way or another. Images are now
missing/broken on pages; files such as PDFs etc. return an error with
traceback always ending in:

  Module zope.tales.expressions, line 217, in __call__
  Module Products.PageTemplates.Expressions, line 155, in _eval
  Module Products.PageTemplates.Expressions, line 117, in render
  Module, line 129, in get_size
  Module, line 52, in openBlob
  Module ZODB.Connection, line 860, in setstate
  Module ZODB.Connection, line 922, in _setstate
  Module ZEO.ClientStorage, line 1020, in loadBlob
POSKeyError: 'No blob file'

I have put back in place the 'lawn' blobstorage for now and the site is
fine again. It needs to stay fine, as it is a county government site
with lots and lots and LOTS of public documents on it.

I would like to migrate to 'bushy' blobstorage, if it is truly important
to do so. However I don't know what to do next to troubleshoot my situation.
I've found some posts about the POSKeyError but they are all, so far,
about corrupted situations of various kinds which I am pretty sure I
don't have. I've not found anything yet relevant to the migration script
producing a 'bushy' migration result that is broken like this.

Any leads appreciated...

John S.

John Schinnerer - M.A., Whole Systems Design
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
[hidden email] - 510.982.1334
Setup mailing list
[hidden email]