The heroes of Fedora updates testing in Q1 2013

1360095720_PrizeRecently I’ve published a list of contributors who helped to test Fedora 19 Alpha. But Quality Assurance doesn’t involve just in-development releases. We need to ensure that stable releases also work well. One of the major ways to achieve that is to make sure that broken package updates don’t enter stable updates repository. We use Bodhi system for that. I have gathered the data about Bodhi feedback contributors regardless of Fedora release involved and present it here.

Who are the heroes who watch the Fedora borders and guard us against broken software updates?

Test period: Q1 2013 (2013-01-01 – 2013-03-31)
Testers: 657
Comments1: 2203

Name Updates commented
hreindl 278
patches 94
kparal 92
mrunge 53
adamwill 48
akshayvyas29 41
mooninite 33
kevin 32
ankursinha 26
rdieter 25
keramidas 25
bojan 23
nucleo 23
boblfoot 20
pwalter 18
cfeller 18
quickbooks 17
bradw 15
amessina 15
sdodson 14
kwizart 14
wolnei 14
bitlord 14
freddyw 14
remi 13
pbrobinson 13
mstevens 13
lkocman 13
misc 13
orion 12
nb 12
artkun 11
nonamedotc 10
ktdreyer 10
ajax 10
jerboaa 10
vicodan 9
po80x-nontoxic at 9
jvanalte 9
erinn 9
cairo 8
stransky 8
greenfeld 8
sysengbd 7
petersen 7
asrob 7
akurtakov 7
ejs1920 7
jmoskovc 7
jpopelka 7
ondrejj 6
mmilata 6
mtoman 6
robatino 6
tsmetana 6
jvcelak 6
wutao85 5
nkinder 5
gtwilliams 5
till 5
kkofler 5
rcritten 5
adomurad 5
ralph 5
bruno 5
ptisnovs 5
tjikkun 5
fabiand 5
rtcm 5
rlandy 5
balay 5
brallan 5
ppisar 5
…and also 584 other reporters who created less than 5 reports each, but 867 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is unimportant.

As you can see, Harald Reindl (hreindl) is completely leading this effort, and no one else is even close. Thank you, Harald!

There are lots of further names from the community. T.C. Hollingsworth (patches) provided an outstanding number of comments, followed by Akshay Vyas (akshayvyas29), mooninite, Ankur Sinha (ankursinha), Rex Dieter (rdieter), Vasileios Keramidas (keramidas), bojan, nucleo, Robert C. Lightfoot (boblfoot) and many more! Thank you, and everyone else who helped with testing Fedora updates, no matter your score.

If you are interested in helping Fedora, this is a very easy way and you can start today! Just read QA:Updates_Testing and ask any questions in #fedora-qa on IRC or test list. It would be great to see more faces around.

Thanks and enjoy the day.

When reading the statistics, please take it with a grain of salt. Not all numbers are directly comparable. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

Impact of “discard” mount option on Intel 525 SSD

1368191239_DriveI have replaced my traditional HDD with an Intel 525 SSD (120 GB, mSATA) recently. To keep the write performance high a TRIM option should be enabled. You can either mount the drive with ‘discard’ option, or you can run fstrim command periodically. (This can be a bit trickier if you have LUKS encrypted partitions).

The discard option performs TRIM immediately when a file is deleted, and there is some performance hit involved. You can work around that by having fstrim in a cron job and trimming the disk just once a day or so. It takes longer (about a minute in my case), but it is not a continuous performance hit.

Two years ago Patrick Nagel published a blog about discard performance on his OCZ Vertex LE (100 GB). I was curious whether the numbers would be the same for my SSD. Let’s have a look.

Test description:
With and without discard option let’s do:

  1. Extract linux sources (linux-3.9.1.tar.gz; 45168 files, 592 MB extracted) including sync operation.
    $ time (tar xzf linux-3.9.1.tar.gz ; sync)
  2. Remove the directory including sync operation.
    $ time (rm linux-3.9.1 -rf; sync)

Of course, a few warmup rounds are included. The numbers are averaged from three passes. I have an ext4 partition on LVM on LUKS.

Without discard
extract: 7,367666667s
delete: 0,709666667s

With discard
extract: 7,373333333s
delete: 2,697333333s

You can also view the raw data.

As you can see, there is a substantial hit on deletion. Removing 45k files was almost 4x slower. But, on the other hand, we’re talking about mere few seconds here, which is way better than in Patrick’s example. I guess the SSD controllers really improved in two years.

I also did a quick second test with deleting a large (3 GB) file. The results are similar – without discard it takes about 0.43s and with discard it takes about 1.65s. So there is no substantial difference between deleting a huge number of smaller files and deleting a single big file.

The output? If you are a general user with no specific needs and you don’t want to bother with cron scripts, you can simply enable the discard option and have your life easier. Of course, we’re talking about Intel 525 here. If you have some other SSD, especially an older one, it might be a good idea to measure the numbers yourself.

Flattr this