list_parts failed before executing rebalance

[Hisashi Osanai]

[Description]
swift-ring-builder list_parts failed before executing swift-ring-builder
rebalance
I think there is no _replica2part2dev object before executing rebalance
in the following code L322.

321 partition_count = {}
322 for replica in builder._replica2part2dev:
323 for partition, device in enumerate(replica):
324 if device in devs:
325 if partition not in partition_count:
326 partition_count[partition] = 0
327 partition_count[partition] += 1

[Version details]
latest master

[Crystal clear details to reproduce the bug]

$ swift-ring-builder account.builder create 3 1 0
$ swift-ring-builder account.builder add --region 1 --zone 1 --ip 172.17.16.4 --port 6002 --replication-ip 172.17.17.4 --replication-port 7002 --device device1 --weight 100
$ swift-ring-builder account.builder list_parts 172.17.16.4

[Test environment details]
-

[Actual results]
$ swift-ring-builder account.builder list_parts 172.17.16.4
Traceback (most recent call last):
  File "/usr/local/bin/swift-ring-builder", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File "/opt/stack/swift/bin/swift-ring-builder", line 24, in <module>
    sys.exit(main())
  File "/opt/stack/swift/swift/cli/ringbuilder.py", line 856, in main
    Commands.__dict__.get(command, Commands.unknown.im_func)()
  File "/opt/stack/swift/swift/cli/ringbuilder.py", line 331, in list_parts
    sorted_partition_count = find_parts(builder, argv)
  File "/opt/stack/swift/swift/common/ring/utils.py", line 322, in find_parts
    for replica in builder._replica2part2dev:
TypeError: 'NoneType' object is not iterable

[Expected results]
exit normally without any partition info.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/139523

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/139523
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=d742b610df8b9edac97506f165993267db37af3e
Submitter: Jenkins
Branch: master

commit d742b610df8b9edac97506f165993267db37af3e
Author: Hisashi Osanai <email address hidden>
Date: Fri Dec 5 23:43:52 2014 +0900

    Fix the behavior of swift-ring-builder list_parts before rebalance

    The swift-ring-builder list_parts before rebalance failed abnormally so
    this patch fix the behavior. After this patch applies the behavior is
    completion normally with the following messages.

    Specified builder file "<builder_file>" is not rebalanced yet.
    Please rebalance first.

    Closes-Bug: #1399529
    Change-Id: I9e5db6da85de4188915c51bc401604733f0e1b77

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: feature/ec
Review: https://review.openstack.org/139870

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/139870
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=132f8b3169cd0b5ba094736b16fbc75ccc11551e
Submitter: Jenkins
Branch: feature/ec

commit cc2f0f4ed6f12554b7d8e8cb61e14f2b103445a0
Author: Samuel Merritt <email address hidden>
Date: Thu Dec 4 18:37:24 2014 -0800

    Speed up reading and writing xattrs for object metadata

    Object metadata is stored as a pickled hash: first the data is
    pickled, then split into strings of length <= 254, then stored in a
    series of extended attributes named "user.swift.metadata",
    "user.swift.metadata1", "user.swift.metadata2", and so forth.

    The choice of length 254 is odd, undocumented, and dates back to the
    initial commit of Swift. From talking to people, I believe this was an
    attempt to fit the first xattr in the inode, thus avoiding a
    seek. However, it doesn't work. XFS _either_ stores all the xattrs
    together in the inode (local), _or_ it spills them all to blocks
    located outside the inode (extents or btree). Using short xattrs
    actually hurts us here; by splitting into more pieces, we end up with
    more names to store, thus reducing the metadata size that'll fit in
    the inode.

    [Source: http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/Extended_Attributes.html]

    I did some benchmarking of read_metadata with various xattr sizes
    against an XFS filesystem on a spinning disk, no VMs involved.

    Summary:

     name | rank | runs | mean | sd | timesBaseline
    ------|------|------|-----------|-----------|--------------
    32768 | 1 | 2500 | 0.0001195 | 3.75e-05 | 1.0
    16384 | 2 | 2500 | 0.0001348 | 1.869e-05 | 1.12809122912
     8192 | 3 | 2500 | 0.0001604 | 2.708e-05 | 1.34210998858
     4096 | 4 | 2500 | 0.0002326 | 0.0004816 | 1.94623473988
     2048 | 5 | 2500 | 0.0003414 | 0.0001409 | 2.85674781189
     1024 | 6 | 2500 | 0.0005457 | 0.0001741 | 4.56648611635
      254 | 7 | 2500 | 0.001848 | 0.001663 | 15.4616067887

    Here, "name" is the chunk size for the pickled metadata. A total
    metadata size of around 31.5 KiB was used, so the "32768" runs
    represent storing everything in one single xattr, while the "254" runs
    represent things as they are without this change.

    Since bigger xattr chunks make things go faster, the new chunk size is
    64 KiB. That's the biggest xattr that XFS allows.

    Reading of metadata from existing files is unaffected; the
    read_metadata() function already handles xattrs of any size.

    On non-XFS filesystems, this is no worse than what came before:

    ext4 has a limit of one block (typically 4 KiB) for all xattrs (names
    and values) taken together [1], so this change slightly increases the
    amount of Swift metadata that can be stored on ext4.

    ZFS let me store an xattr with an 8 MiB value, so that's plenty. It'll
    probably go further, but I stopped there.

    [1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes

    Change-Id: Ie22db08ac0050eda693de4c30d4bc0d...