Server Technical Specification Working Session
> 16:06:36 <sgallagh> simo: To answer your question about overcommit: that is *possible*, but we can be smarter about it in the default partitioning
Anaconda currently disallows overcommitting.
> 15:48:19 <mitr> (Again, having a per-directory instead of per-user quotas would be rather beneficial here)
A related item that came up is quotas. XFS supports project quotas. So that's possible in the case where you're on the fence if something should have a separate LV. Project quotas were just proposed as an ext4 feature last month.
My two small concerns about LVM thinp by default:
1. XFS is highly parallel + the parallel writes is a trigger for the current thinp fragmentation issue. So it's a "good" combination to reveal this problem.
2. There is an outstanding bug between XFS and LVMthinp that I think the LVM folks might need to be pinged on. The wrong number of XFS AG's is being assigned to virtual size LVs and this will reduce performance.
On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de> wrote:
> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote:
>> A question I have is XFS worth it?
> I have done some testing with RHEL 7 Beta which use XFS as a default file system.
> I have to recorgnize, that the -r switch of the lvresize command doesn't cooperate
> with xfs in oppoiste of ext4.
Where you growing or shrinking the fs, and was it mounted at the time, and what error did you get? XFS doesn't support shrink, and only can be grown online. I'm pretty sure lvresize -r supports xfs_growfs via fsadm.
Recently I have been looking into our lookaside tree. The tree is built as such:
I ran into such situation:
where as you can see a single tarball as 3 different md5 sums.
So I got curious as to how often do we encounter this situation. I got the
output of the tree command on the lookaside cache and looked into it.
The summary data is:
173083 sources checked
2672 packages skipped because retired
5568 packages had multiple md5 for at least 1 of their version
That's about 3.22% (of the total)
Speaking about it at the infrastructure meeting yesterday we discussed that
there might multiples causes for this:
- bad upload, something just went wrong when uploading
- mistake upstream, upstream releasing another tarball with the same name
- mistake from the packager, where the packager re-generated or changed the
tarball and upload it.
So this morning I look at the size of the tarball uploaded. I think some case
are clear example of bad upload:
Curious package 389-ds-base sources: 389-ds-base-188.8.131.52.tar.bz2
While don't quite look like bad uploads:
Curious package 0ad sources: 0ad-0.0.12-alpha-unix-build.tar.xz
So I am attaching to this email the full output with the sizes, feel free to
have a look at it and please, try to avoid uploading modified tarball with
the same name or try to work with upstream to avoid these situations.
Just a side note: this has no impact on our build system as it uses the
`sources` file present in the git repo which contains the md5 sum to use, so it
will use the right one :)
Hope this helps,
Hello! My name is James Wilson Harshaw IV. I have been using Fedora for
a few years now, but recently really wanted to get more involved.
I have a pretty good amount of knowledge in C, C++, PHP, Perl, Golang,
and Java. I hope to use this knowledge to benefit the project.
A little about me: I am a college student, studying computer science and
am currently employed as a freelance backend web developer. I have a
strong passion for Linux, Open Source Software, and coffee.
I look forward to getting to know and work with you all!
P.S I currently have a sponsor request:
(sent again because I am not sure this went through.
= Proposed System Wide Change: Remove python-setuptools-devel =
Change owner(s): Toshio Kuratomi <toshio(a)fedoraproject.org>
The python-setuptools package has carried a virtual Provide for python-
setuptools-devel since 2009 for backwards compatibility. We're going to remove
this virtual Provide. Packages which still BuildRequire python-setuptools-
devel will need to be updated to Require: python-setuptools instead.
== Detailed description ==
In November of 2009, in time for Fedora 13, we solved a packaging issue in the
main python package that allowed us to remove a split in our python-setuptools
package. Instead of needing a separate python-setuptools-devel subpackage for
easy_install the python-setuptools package could now contain all of the
functionality of python-setuptools. To ease with package migration we added an
Obsoletes and Provides tag to the python-setuptools package at that time so
that packages, kickstarts, etc which required python-setuptools-devel would
Fast forward to the present day:
It's December of 2013. Rawhide is Fedora 21. I'd like to drop the backwards
compatibility Provides (and Obsoletes) from the python-setuptools package.
However, there are currently 151 packages BuildRequire'ing python-setuptools-
devel. This Change exists to make people aware that they need to update their
== Scope ==
* Proposal owners: Remove the Provides: and Obsoletes: python-setuptools-devel
in the python-setuptools package and rebuild. This will take approximately 30
* Other developers: Owners of packagers that BuildRequire: python-setuptools-
devel need to change to BuildRequire: python-setuptools and rebuild.
Individually, this takes approximately 30 minutes per package (but largely
waiting on builds to finish successfully). There are approximately 151 packages
* Release engineering: No action needed by rel-eng. Until other developers
update their BuildRequires, their packages would fail to rebuild in a mass
* Policies and guidelines: No action needed. The packaging guidelines have
already been changed to use BuildRequires: python-setuptools rather than
devel-announce mailing list
-----BEGIN PGP SIGNED MESSAGE-----
On 02/27/2014 07:53 AM, Rui Tiago Cação Matos wrote:
> On 27 February 2014 13:43, Stephen Gallagher <sgallagh(a)redhat.com>
>> Formal proposal (for discussion): All three products agree to use
>> ext4 for /boot and XFS-on-LVM for all other partitions in the
>> "guided" mode. All is fair game in the "custom" mode.
> What's the point of using LVM for the root filesystem?
As it happens, I can cite a perfect example of this from my own
experiences in the last week :)
I have a hard drive in the Fedora server I run in my basement that has
started throwing intermittent I/O errors. Fortunately for me, I set it
up on LVM. I went out, bought a new hard drive, inserted it, added it
to the volume group and then ran 'pvmove' to migrate all of the
sectors off of the original drive to the new one. Once that was done,
I could safely remove the defective drive from the volume group.
Zero downtime, perfect recovery.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----