GitHub PushEvent at 2014-12-10 15:14:54
Repository: swift
Actor: citrix-openstack-build
Payload: {"shas":[["c52795e263ab40d29baf1177812a5c93d15fbb26","f23d94b2a735b6193d3882ae31308d2e41e8282b@redhat.com","Fix container quota check during cross-account COPY\n\nContainer quota is not currently checking Destination-Account header\nwhich could cause quota to not be enforced in case of copies\n\nChange-Id: I43adb0d7d2fc14ba6c0ca419a52a5c3f138f799a\nSigned-off-by: Thiago da Silva <thiago@redhat.com>","Thiago da Silva",false],["83834eb2769a6dd4193e514007abcdbfa4241001","5908cf536e9267f3c74e45326928d92a7461a903@gmail.com","Raise ValueError for offset on Timestamp over limit\n\nWe can't order a Timestamp with an offset larger than 16 hex digits\ncorrectly, so we raise a ValueError if you try to create one.\n\nChange-Id: I8c8d4cf13785a1a8eb7416392263eae5242aa407","Clay Gerrard",false],["d40cebfe55a2ef63e0fdceb21548587bad497a69","e12af2ca3db85a046a621e59d5f1e59e36fb3204@gmail.com","Clean up empty account and container partitions directories.\n\nBecause we iterate over these directories on a replication run,\nand they are not (previously) cleaned up, the time to start the\nreplication increases incrementally for each stale directory\nlying around.  Thousands of directories across dozens of disks\non a single machine can make for non-trivial startup times.\n\nPlus it just seems like good housekeeping.\nCloses-Bug: #1396152\n\nChange-Id: Iab607b03b7f011e87b799d1f9af7ab3b4ff30019","Caleb Tennis",false],["233e0aebf77022074f328d26cb54490115e2127b","5908cf536e9267f3c74e45326928d92a7461a903@gmail.com","Fix reclaim on deleted containers\n\nThe common db replicator's code path for reclaiming deleted db's beyond the\nreclaim age was not covered by unittests, and a AttributeError snuck in.  In\nwriting the test that would cover the common code both for accounts and\ncontainers I discovered another KeyError with the container conditional for\nvalidating the container's fully reported status.\n\nThis fixes both those issues and adds additional tests for the cleanup empty\naccount container partition and suffix directories.\n\nChange-Id: I2a1bfaefebd05b01231bf71dd908fcc49adb4c36","Clay Gerrard",false],["4a1996c3eeb7d78b18f641988772b45788284dce","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"Clean up empty account and container partitions directories.\"","Jenkins",false],["f8e4ab509b36a82c3fd9ec0c823d7909b5d5bc38","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"Fix reclaim on deleted containers\"","Jenkins",false],["c8ef11d677ef2403f8cc084f6893815f96985c68","b1c1d8736f20db3fb6c1c66bb1455ed43909f0d8@not.mn","added testing notes to the contributing doc\n\nChange-Id: Ifb83469dabbca435bd3df2c05089dc1a113c4460","John Dickinson",false],["e129c7cc770fc23ef25fc12f100300f82e791b31","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"Fix container quota check during cross-account COPY\"","Jenkins",false],["7a7cdf3d6a2e2078658df3783170b68f25973db1","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"Raise ValueError for offset on Timestamp over limit\"","Jenkins",false],["96439301a2d87776482af5d0b4b5fd3bac27d432","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"added testing notes to the contributing doc\"","Jenkins",false],["a3b192614dbff709237b6269932980e4f04017a2","98883b97e35b7bb1ac282bb863f2e9d917db0454@yuggoth.org","Workflow documentation is now in infra-manual\n\nReplace URLs for workflow documentation to appropriate parts of the\nOpenStack Project Infrastructure Manual.\n\nChange-Id: I060e5f6869fd302a47a54556f31763b5ab668012","Jeremy Stanley",false],["d742b610df8b9edac97506f165993267db37af3e","e49e4e527f4cd5c299a75e1c8e0b181aeadfc549@jp.fujitsu.com","Fix the behavior of swift-ring-builder list_parts before rebalance\n\nThe swift-ring-builder list_parts before rebalance failed abnormally so\nthis patch fix the behavior. After this patch applies the behavior is\ncompletion normally with the following messages.\n\nSpecified builder file \"<builder_file>\" is not rebalanced yet.\nPlease rebalance first.\n\nCloses-Bug: #1399529\nChange-Id: I9e5db6da85de4188915c51bc401604733f0e1b77","Hisashi Osanai",false],["b6e4c8314fe038e820960c31bdfc5ba4a6701366","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"Workflow documentation is now in infra-manual\"","Jenkins",false],["cc2f0f4ed6f12554b7d8e8cb61e14f2b103445a0","f16bed56189e249fe4ca8ed10a1ecae60e8ceac0@swiftstack.com","Speed up reading and writing xattrs for object metadata\n\nObject metadata is stored as a pickled hash: first the data is\npickled, then split into strings of length <= 254, then stored in a\nseries of extended attributes named \"user.swift.metadata\",\n\"user.swift.metadata1\", \"user.swift.metadata2\", and so forth.\n\nThe choice of length 254 is odd, undocumented, and dates back to the\ninitial commit of Swift. From talking to people, I believe this was an\nattempt to fit the first xattr in the inode, thus avoiding a\nseek. However, it doesn't work. XFS _either_ stores all the xattrs\ntogether in the inode (local), _or_ it spills them all to blocks\nlocated outside the inode (extents or btree). Using short xattrs\nactually hurts us here; by splitting into more pieces, we end up with\nmore names to store, thus reducing the metadata size that'll fit in\nthe inode.\n\n[Source: http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/Extended_Attributes.html]\n\nI did some benchmarking of read_metadata with various xattr sizes\nagainst an XFS filesystem on a spinning disk, no VMs involved.\n\nSummary:\n\n name | rank | runs |      mean |        sd | timesBaseline\n------|------|------|-----------|-----------|--------------\n32768 |    1 | 2500 | 0.0001195 |  3.75e-05 |           1.0\n16384 |    2 | 2500 | 0.0001348 | 1.869e-05 | 1.12809122912\n 8192 |    3 | 2500 | 0.0001604 | 2.708e-05 | 1.34210998858\n 4096 |    4 | 2500 | 0.0002326 | 0.0004816 | 1.94623473988\n 2048 |    5 | 2500 | 0.0003414 | 0.0001409 | 2.85674781189\n 1024 |    6 | 2500 | 0.0005457 | 0.0001741 | 4.56648611635\n  254 |    7 | 2500 |  0.001848 |  0.001663 | 15.4616067887\n\nHere, \"name\" is the chunk size for the pickled metadata. A total\nmetadata size of around 31.5 KiB was used, so the \"32768\" runs\nrepresent storing everything in one single xattr, while the \"254\" runs\nrepresent things as they are without this change.\n\nSince bigger xattr chunks make things go faster, the new chunk size is\n64 KiB. That's the biggest xattr that XFS allows.\n\nReading of metadata from existing files is unaffected; the\nread_metadata() function already handles xattrs of any size.\n\nOn non-XFS filesystems, this is no worse than what came before:\n\next4 has a limit of one block (typically 4 KiB) for all xattrs (names\nand values) taken together [1], so this change slightly increases the\namount of Swift metadata that can be stored on ext4.\n\nZFS let me store an xattr with an 8 MiB value, so that's plenty. It'll\nprobably go further, but I stopped there.\n\n[1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes\n\nChange-Id: Ie22db08ac0050eda693de4c30d4bc0d620e7f7d4","Samuel Merritt",false]],"size":14,"ref":"refs/heads/ctx-nova-network-full-latest","head":"cc2f0f4ed6f12554b7d8e8cb61e14f2b103445a0"}