FAQ
<https://www.centos.org/modules/newbb/viewtopic.php?topic_id%878&forumS>

My current understanding is that the ongoing build of CentOS 6.0 is still
running in minimal mode. I expect it to pick up speed once all the current
CentOS 5.6 updates have been built and pushed to the update queue.

I will be discussing the 6.0 build status with Karanbir in the next few
days and hopefully will have something a little less tenuous to report
early-ish next week.

I think it is fair to say that as CentOS 6.0 is a new entry into the
product line, it may spend somewhat more time in QA whilst the critical
eyes give it close scrutiny.

--
Alan

Presumably, this means that it is reasonable to expect a longer window than
the early optimistic estimates of two weeks after the CentOS 5.6 release.


--
Matthew Miller mattdm at mattdm.org <http://mattdm.org/>

Search Discussions

  • Yury V. Zaytsev at Apr 26, 2011 at 11:20 am

    On Fri, 2011-04-15 at 12:12 -0400, Matthew Miller wrote:

    Presumably, this means that it is reasonable to expect a longer window than
    the early optimistic estimates of two weeks after the CentOS 5.6 release.
    Is there any update on what's going on the CentOS 6 front?

    The last update in the forums have been published on Apr. 14, the last
    tweet was on Apr. 18 and nothing has been posted on the list either. I
    am not following CentOS-Users, but it is reasonable to expect that if
    any official update was posted there for it to be cross-posted here as
    well.

    Thanks!

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Jeff Sheltren at Apr 26, 2011 at 11:25 am

    On Tue, Apr 26, 2011 at 8:20 AM, Yury V. Zaytsev wrote:
    On Fri, 2011-04-15 at 12:12 -0400, Matthew Miller wrote:

    Presumably, this means that it is reasonable to expect a longer window than
    the early optimistic estimates of two weeks after the CentOS 5.6 release.
    Is there any update on what's going on the CentOS 6 front?

    The last update in the forums have been published on Apr. 14, the last
    tweet was on Apr. 18 and nothing has been posted on the list either. I
    am not following CentOS-Users, but it is reasonable to expect that if
    any official update was posted there for it to be cross-posted here as
    well.
    A build and QA plan is being worked out now with the QA team. I
    expect that once this is finalized there will be a statement from a
    CentOS dev with more details.

    -Jeff
  • Bill McGonigle at May 6, 2011 at 2:49 am

    On 04/26/2011 11:25 AM, Jeff Sheltren wrote:
    A build and QA plan is being worked out now with the QA team. I
    expect that once this is finalized there will be a statement from a
    CentOS dev with more details.
    via Twitter, 5:13 AM May 3rd:

    CentOS-6 release plan, target-1) tree's to QA by 10th May

    --
    Bill McGonigle, Owner
    BFC Computing, LLC
    http://bfccomputing.com/
    Telephone: +1.603.448.4440
    Email, IM, VOIP: bill at bfccomputing.com
    VCard: http://bfccomputing.com/vcard/bill.vcf
    Social networks: bill_mcgonigle/bill.mcgonigle
  • Mike Doroshenko at May 6, 2011 at 3:47 pm

    On 05/06/2011 12:49 AM, Bill McGonigle wrote:
    target-1) tree's to QA
    What does/target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but/tree's to Quality Assurance/ still doesn't make sense to me.

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110506/425b39b0/attachment.html
  • Johnny Hughes at May 6, 2011 at 4:01 pm

    On 05/06/2011 02:47 PM, Mike Doroshenko wrote:
    On 05/06/2011 12:49 AM, Bill McGonigle wrote:
    target-1) tree's to QA
    What does /target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but /tree's to Quality Assurance/ still doesn't make sense to me.
    If you look on mirror.centos.org, what we consider a "Tree" is the 5.6
    directory or the 4.8 directory.

    In this particular case, we are saying that we will get all the RPMs
    (built) in the 6.0 to QA to look at.

    They will be installable as RPMs from the directory (ie, like the
    updates directory).

    We may have network installable boot images at that point, but we will
    not have a full set of installable / bootable ISOs.

    Once we run several sets of tests in QA with many kinds of installs (or
    updating over other installs for other than the .0 releases) and once we
    fix issues found with these RPMS, then we will generate the actual
    install ISOs and test those.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110506/76b7c7a0/attachment.bin
  • Johnny Hughes at May 6, 2011 at 4:24 pm

    On 05/06/2011 03:01 PM, Johnny Hughes wrote:
    On 05/06/2011 02:47 PM, Mike Doroshenko wrote:
    On 05/06/2011 12:49 AM, Bill McGonigle wrote:
    target-1) tree's to QA
    What does /target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but /tree's to Quality Assurance/ still doesn't make sense to me.
    If you look on mirror.centos.org, what we consider a "Tree" is the 5.6
    directory or the 4.8 directory.

    In this particular case, we are saying that we will get all the RPMs
    (built) in the 6.0 to QA to look at.

    They will be installable as RPMs from the directory (ie, like the
    updates directory).

    We may have network installable boot images at that point, but we will
    not have a full set of installable / bootable ISOs.

    Once we run several sets of tests in QA with many kinds of installs (or
    updating over other installs for other than the .0 releases) and once we
    fix issues found with these RPMS, then we will generate the actual
    install ISOs and test those.
    Some of the tests that we run in this stage (where we have all the RPMs,
    but not necessarily an installable distro) is:

    1. All the RPMs seemed to install properly on a running system.

    2. That the dynamic libraries linked by all the libraries/binaries are
    the same as upstream.

    3. That the file list of every RPM we produced is identical to the file
    list of every RPM from upstream.

    4. That the trees contain the correct versions of all files (the same
    ones on the .0 isos from upstream). We want to make sure the updates go
    into the updates directory.

    5. That the comps.xml (compilation) file has the correct groups in it.
    Upstream has several different versions of their codebase that they
    sell for different amounts ... ie:
    a. Server
    b. Workstation
    c. Desktop

    CentOS has no need for the segregation, our product is free and contains
    all the packages (and yum install groups, etc.) from all of those combined.

    We also remove several packages (all the RHN items, for example, since
    CentOS is not allowed to update from RHN, etc.)

    This requires us to take the applicable portions of several comps files
    and build a combined comps file that allows you to install Servers,
    Desktops, Workstations, etc.

    6. In the case of 6.0 specifically, there is an "optional" channel that
    contains many of the -devel (development) files needed to build things.
    We also have no need for that, but we need to get the items in that
    channel integrated into our distribution and comps files.


    Once we get all of these things done and tested, then we can generate a
    set of real ISOs and test the install groups, etc.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110506/82aafb93/attachment.bin
  • David Hrbáč at May 6, 2011 at 4:47 pm

    Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
    We also remove several packages (all the RHN items, for example, since
    CentOS is not allowed to update from RHN, etc.)
    Yes, but these packages might be important for Spacewalk deployment. So
    I'd prefer to modify these packages and release.
    DH
  • Thomas Göttgens at May 6, 2011 at 6:03 pm
    Hi David,

    all the neccessary packages are in the spacewalk-client repo anyway.
    Plus as of Spacewalk 1.4 they can be provisioned from the server quite easily.
    Why duplicate work? These are not really needed for a standalone
    CentOS.

    am Freitag, 6. Mai 2011 um 22:47 schrieben Sie:
    Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
    We also remove several packages (all the RHN items, for example, since
    CentOS is not allowed to update from RHN, etc.)
    Yes, but these packages might be important for Spacewalk deployment. So
    I'd prefer to modify these packages and release.
    DH
    --
    Mit freundlichen Gr??en
    Thomas G?ttgens
    mailto:tgoettgens at gmail.com
  • David Hrbáč at May 7, 2011 at 4:17 pm

    Dne 7.5.2011 00:03, Thomas G?ttgens napsal(a):
    Hi David,

    all the neccessary packages are in the spacewalk-client repo anyway.
    Plus as of Spacewalk 1.4 they can be provisioned from the server quite easily.
    Why duplicate work? These are not really needed for a standalone
    CentOS.
    Thomas,
    This is not the duplication. First of all you have to register the
    system into Spacewalk. So you need rhnreg_ks, which is in
    rhn-setup-1.3.12-1.el5. One must install spacewalk-repo-client package
    first.
    Regards,
    DH
  • Karanbir Singh at May 6, 2011 at 6:18 pm

    On 05/06/2011 09:47 PM, David Hrb?? wrote:
    Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
    We also remove several packages (all the RHN items, for example, since
    CentOS is not allowed to update from RHN, etc.)
    Yes, but these packages might be important for Spacewalk deployment. So
    I'd prefer to modify these packages and release.
    The space walk guys seem to prefer not having the code in the distro,
    and just use the latest / greatest from the spacewalk repo's; has that
    mindset changed in the recent past ? ( since we had the chat on this
    list last anyway .. )

    - KB
  • David Hrbáč at May 7, 2011 at 4:17 pm

    Dne 7.5.2011 00:18, Karanbir Singh napsal(a):
    The space walk guys seem to prefer not having the code in the distro,
    and just use the latest / greatest from the spacewalk repo's; has that
    mindset changed in the recent past ? ( since we had the chat on this
    list last anyway .. )

    - KB
    I'm not talking about following Spacewalk. Having just "old" package for
    bootstrapping would be fine and useful. So one can easily register into
    Spacewalk and update spacewalk client from Spacewalk channel then.
    DH
  • R P Herrold at May 7, 2011 at 11:35 am

    On Fri, 6 May 2011, David Hrb?? wrote:

    Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
    We also remove several packages (all the RHN items, for example, since
    CentOS is not allowed to update from RHN, etc.)
    Yes, but these packages might be important for Spacewalk deployment. So
    I'd prefer to modify these packages and release.
    Thinking out loud here ...

    The question then becomes: how to test these? We'll need a
    'cookbook' or automated process for setting up the needed test
    harness infrastructure, and then the functional tests, if
    these parts were to be retained ...

    By and large, the only non-end-user posters 'in quantity' on
    the spacewalk mailing lists seem to be @redhat folks, and so
    the utility of such an effort is not clear

    -- Russ herrold
  • Yury V. Zaytsev at May 30, 2011 at 8:55 am
    Hi!

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Fabian Arrotin at May 30, 2011 at 9:27 am

    On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
    Hi!

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    No and the current tree isn't complete either

    Fabian
  • Yury V. Zaytsev at May 30, 2011 at 9:29 am

    On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
    On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
    Hi!

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    No and the current tree isn't complete either
    Thanks for the update!

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Patrice Guay at May 30, 2011 at 10:09 am

    On Mon, May 30, 2011 9:29 am, Yury V. Zaytsev wrote:
    On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
    On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
    Hi!

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    No and the current tree isn't complete either
    Thanks for the update!
    Would it be possible to update the QAWeb calendar accordingly?

    --
    Patrice Guay
    patrice.guay at nanotechnologies.qc.ca
  • Alan Bartlett at May 30, 2011 at 1:30 pm

    On 30 May 2011 15:09, Patrice Guay wrote:
    On Mon, May 30, 2011 9:29 am, Yury V. Zaytsev wrote:
    On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
    On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    No and the current tree isn't complete either
    Thanks for the update!
    Would it be possible to update the QAWeb calendar accordingly?
    Jeff ?? Where are you ?

    Alan.
  • John R. Dennison at May 30, 2011 at 1:35 pm

    On Mon, May 30, 2011 at 06:30:16PM +0100, Alan Bartlett wrote:
    Jeff ?? Where are you ?
    You're aware that today is a US federal holiday?




    John

    --
    There's only one way to have a happy marriage and as soon as I learn what it
    is I'll get married again.

    -- Clint Eastwood
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110530/0ca6a4cf/attachment.bin
  • Alan Bartlett at May 30, 2011 at 1:38 pm

    On 30 May 2011 18:35, John R. Dennison wrote:
    On Mon, May 30, 2011 at 06:30:16PM +0100, Alan Bartlett wrote:
    Jeff ?? ?Where are you ?
    You're aware that today is a US federal holiday?
    Bah! Humbug!

    The CentOS Project is not US of A-centric. :P

    FYI, today is a UK Bank Holiday!

    Alan.
  • Jeff Sheltren at May 30, 2011 at 5:38 pm

    On Mon, May 30, 2011 at 10:38 AM, Alan Bartlett wrote:
    On 30 May 2011 18:35, John R. Dennison wrote:
    On Mon, May 30, 2011 at 06:30:16PM +0100, Alan Bartlett wrote:
    Jeff ?? ?Where are you ?
    You're aware that today is a US federal holiday?
    Bah! Humbug!
    I'm around, but enjoying time away from the computer today. There is
    some progress being made on QA -- will update the calendar
    accordingly.

    -Jeff
  • Karanbir Singh at May 30, 2011 at 6:40 pm

    On 05/30/2011 01:55 PM, Yury V. Zaytsev wrote:
    Hi!

    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    the isos are uploading at the moment, will try and put some of this
    stuff into a blog post on the qaweb interface

    - KB
  • Jeff Sheltren at May 31, 2011 at 8:12 pm

    On Mon, May 30, 2011 at 3:40 PM, Karanbir Singh wrote:
    Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
    the isos are uploading at the moment, will try and put some of this
    stuff into a blog post on the qaweb interface
    I posted an update here:
    http://qaweb.dev.centos.org/qa/node/82

    Will get the calendar updated soon.

    -Jeff
  • Andrzej Szymański at Jun 1, 2011 at 1:52 pm

    On 2011-05-31 00:40, Karanbir Singh wrote:
    the isos are uploading at the moment, will try and put some of this
    stuff into a blog post on the qaweb interface

    - KB
    I don't know whether you use (and can use) the following hack to speed
    up rsyncing the iso files:

    - you need to have the full (or mostly complete) package tree on the target

    - on the target machine manually make the tar archive out of already
    rsynced package tree, rename that tar to CentOS-whatever_it_is.iso so
    that it pretends to be the older version of the real .iso

    - rsync the real iso (CentOS-whatever_it_is.iso) over this template iso

    The test made with CentOS-5.6-x86_64-bin-DVD-1of2.iso shows:

    sent 186234656 bytes received 521538 bytes 3626333.86 bytes/sec
    total size is 4249268224 speedup is 22.75

    Just my 2 cents...

    Andrzej
  • Karanbir Singh at Jun 2, 2011 at 6:21 am
    Hi,
    On 06/01/2011 06:52 PM, Andrzej Szyma?ski wrote:
    I don't know whether you use (and can use) the following hack to speed
    up rsyncing the iso files:

    - you need to have the full (or mostly complete) package tree on the target
    We do some sanity tests that span the buildsys, the intermediary host
    and the final rsync targets. So its important that the first set of
    contents is sync'd out from the buildsys as-is. Perhaps extra caution,
    but we have had problems in the past ( even with rsync saying two files
    are identical when they were clearly not ).

    On the other hand, the ISOS can be fairly easily re-created from the
    tree, so if the rpms tree are is already in place that would be easier
    than going down the tar route.

    - KB
  • Ferry Huberts at Jun 2, 2011 at 8:15 am

    On 06/02/2011 12:21 PM, Karanbir Singh wrote:
    Hi,
    On 06/01/2011 06:52 PM, Andrzej Szyma?ski wrote:
    I don't know whether you use (and can use) the following hack to speed
    up rsyncing the iso files:

    - you need to have the full (or mostly complete) package tree on the target
    We do some sanity tests that span the buildsys, the intermediary host
    and the final rsync targets. So its important that the first set of
    contents is sync'd out from the buildsys as-is. Perhaps extra caution,
    but we have had problems in the past ( even with rsync saying two files
    are identical when they were clearly not ).
    if it's that important: rsync --checksum
    it's expensive but will guarantee identity
    On the other hand, the ISOS can be fairly easily re-created from the
    tree, so if the rpms tree are is already in place that would be easier
    than going down the tar route.

    - KB
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel

    --
    Ferry Huberts
  • Karanbir Singh at Jun 2, 2011 at 10:24 am

    On 06/02/2011 01:15 PM, Ferry Huberts wrote:
    if it's that important: rsync --checksum
    it's expensive but will guarantee identity
    it actually does not, the -c option was tried at the time as well. It
    turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's
    to say there are no more of those!

    - KB
  • Ferry Huberts at Jun 2, 2011 at 11:01 am

    On 06/02/2011 04:24 PM, Karanbir Singh wrote:
    On 06/02/2011 01:15 PM, Ferry Huberts wrote:
    if it's that important: rsync --checksum
    it's expensive but will guarantee identity
    it actually does not, the -c option was tried at the time as well. It
    turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's
    to say there are no more of those!
    ah, that would be a problem yes ;-)

    keep up the good work!
    --
    Ferry Huberts
  • Karanbir Singh at Jun 2, 2011 at 12:13 pm

    On 06/02/2011 04:01 PM, Ferry Huberts wrote:
    it actually does not, the -c option was tried at the time as well. It
    turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's
    to say there are no more of those!
    ah, that would be a problem yes ;-)
    I just realised that no mention was made of the problem - we had a
    situation in 5.2 release days where a repomd file with a clearly
    different timestamp was being considered by rsync to be identical, even
    with the -c flag on. Similarly we had issues with the comps-extras rpms
    being considered identical when they clearly were not, resigning the
    package also made no difference.

    keep up the good work!

    thanks
  • Phil Schaffner at Jun 2, 2011 at 8:49 am

    Karanbir Singh wrote on 06/02/2011 06:21 AM:
    On the other hand, the ISOS can be fairly easily re-created from the
    tree, so if the rpms tree are is already in place that would be easier
    than going down the tar route.
    Seems that would help a lot with the limited QA upload bandwidth that
    apparently delayed the initial unified tree.

    Publishing a recipe for doing it would save a lot of people a lot of
    time and bandwidth for QA downloads, as well as releases for the
    community. The current procedure on the Wiki

    http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia

    fails with a package tree for lack of a .discinfo file. If there is a
    simple process for creating one it could be incorporated into the script.

    Phil
  • Karanbir Singh at Jun 2, 2011 at 10:25 am

    On 06/02/2011 01:49 PM, Phil Schaffner wrote:
    http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia

    fails with a package tree for lack of a .discinfo file. If there is a
    simple process for creating one it could be incorporated into the script.

    i dont know whats on the end of that wiki article, am http less at the
    moment - however, even the cd's should have a .discinfo

    - KB
  • Phil Schaffner at Jun 2, 2011 at 2:58 pm

    Karanbir Singh wrote on 06/02/2011 10:25 AM:
    On 06/02/2011 01:49 PM, Phil Schaffner wrote:
    http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia

    fails with a package tree for lack of a .discinfo file. If there is a
    simple process for creating one it could be incorporated into the script.

    i dont know whats on the end of that wiki article, am http less at the
    moment - however, even the cd's should have a .discinfo
    The Wiki article mainly comprises a script, originally by Chris Kloiber
    <ckloiber at redhat.com> with tweaks by yours truly, that can build a DVD
    iso from CDs, or a package tree - given that a .discinfo file is
    available. If there are no ISOs yet available, as for instance with the
    current QA tree, the script does not know how to create a .discinfo on
    the fly, nor do I. I did look around a bit in the past (that being
    circa 2008) but failed to come up with the formula; however, I would
    assume the developers must know the correct magic incantation.

    It occurs to me while writing this that the script also does not know
    how to split things up if more than one DVD is required, as that was not
    a concern when the script was created, nor when I modified it for the Wiki.

    Phil
  • Karanbir Singh at Jun 2, 2011 at 10:20 pm

    On 06/02/2011 07:58 PM, Phil Schaffner wrote:
    available. If there are no ISOs yet available, as for instance with the
    current QA tree, the script does not know how to create a .discinfo on
    the fly, nor do I. I did look around a bit in the past (that being
    circa 2008) but failed to come up with the formula; however, I would
    assume the developers must know the correct magic incantation.
    the .discinfo and .treeinfo are created when the installer builds, and
    it contains content that needs to be in sync with the installer images -
    so manually creating it isnt going to cut it :)

    - KB
  • Shawn Thompson at Jun 4, 2011 at 11:48 pm
    If you want to be symbolic, I highly recommend you release this next
    Friday. Since I can already see everyone comparing this to be the
    Linux equivalent to Duke Nukem Forever, releasing it on the same day
    would be a suiting irony.

    ~Shawn
    On Thu, Jun 2, 2011 at 8:20 PM, Karanbir Singh wrote:
    On 06/02/2011 07:58 PM, Phil Schaffner wrote:
    available. ?If there are no ISOs yet available, as for instance with the
    current QA tree, the script does not know how to create a .discinfo on
    the fly, nor do I. ?I did look around a bit in the past (that being
    circa 2008) but failed to come up with the formula; however, I would
    assume the developers must know the correct magic incantation.
    the .discinfo and .treeinfo are created when the installer builds, and
    it contains content that needs to be in sync with the installer images -
    so manually creating it isnt going to cut it :)

    - KB
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Charles Polisher at Jun 2, 2011 at 10:15 am

    Karanbir Singh wrote:
    Hi,

    Andrzej Szyma?ski wrote:
    I don't know whether you use (and can use) the following hack to speed
    up rsyncing the iso files:

    - you need to have the full (or mostly complete) package tree on the target
    We do some sanity tests that span the buildsys, the intermediary host
    and the final rsync targets. So its important that the first set of
    contents is sync'd out from the buildsys as-is. Perhaps extra caution,
    but we have had problems in the past ( even with rsync saying two files
    are identical when they were clearly not ).

    On the other hand, the ISOS can be fairly easily re-created from the
    tree, so if the rpms tree are is already in place that would be easier
    than going down the tar route.
    I found out the hard way in a large production setting
    about rsync parameters that were "new to me":

    --bwlimit=0
    (Don't throttle transfers that run "too quickly")

    --whole-file
    (don't use the delta-xfer algorithm,
    the whole file needs replacing)

    --sockopts=TCP_NODELAY
    (_might_ be useful, you'd have to test
    if it helps on your system)

    and apropos of well-defined behavior, you might have
    overlooked:

    --delay-updates

    This option puts the temporary file from each
    updated file into a holding directory until the
    end of the transfer, at which time all the files
    are renamed into place in rapid succession. This
    attempts to make the updating of the files a
    little more atomic.
    --
    Charles Polisher
  • Karanbir Singh at Jun 2, 2011 at 10:27 am

    On 06/02/2011 03:15 PM, Charles Polisher wrote:
    and apropos of well-defined behavior, you might have
    overlooked:

    --delay-updates
    the msync machines all run with this option set, since it can take a
    while to get 20 odd Gigs per release into place across 90 odd machines :D

    Thanks for the tips and helpful feedback.

    - KB

Related Discussions

People

Translate

site design / logo © 2022 Grokbase