Neal, thanks for the feedback. After taking your comments into
consideration, here's version 2.
| ID | Compression type | Index size |
| Compressed Index | Compressed Dict |
| Chunk | Chunk | ==> More chunks
'\0ZCK1', identifies file as zchunk version 1 file
Type of compression used to compress dict and chunks
0 - Uncompressed
2 - zstd
This is a 64-bit unsigned integer containing the size of compressed
This is the index, which is described in the next section. The index
is compressed without a custom dictionary.
Compressed Dict (optional)
This is a custom dictionary used when compressing each chunk.
Because each chunk is compressed completely separately from the
others, the custom dictionary gives us much better overall
compression. The custom dictionary is compressed without a custom
dictionary (for obvious reasons).
This is a chunk of data, compressed with the custom dictionary
| Checksum type | Checksum of all data |
| Dict checksum | End of dict |
| Chunk checksum | End of chunk | ==> More
This is the type of checksum used to generate the checksums in the
0 = SHA-256
Checksum of all data
This is the checksum of the compressed dict and all the compressed
chunks, used to verify that the file is actually the same, even in
the unlikely event of a hash collision for one of the chunks
This is the checksum of the compressed dict, used to detect whether
two dicts are identical. If there is no dict, the checksum must be
End of dict
This is the location of the end of the dict starting from the end of
the index. This gives us the information we need to find and
decompress the dict. If there is no dict, the checksum must be all
This is the checksum of the compressed chunk, used to detect whether
any two chunks are identical.
End of chunk
This is the location of the end of the chunk starting from the end of
the index. This gives us the information we need to find and
decompress each chunk.
The index is designed to be able to be extracted from the file on the
server and downloaded separately, to facilitate downloading only the
parts of the file that are needed, but must then be re-embedded when
assembling the file so the user only needs to keep one file.
we are now in the infrastructure freeze leading up to the Fedora 27 Beta
release. This is a pre-release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 27 Beta when it's available.
You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2017-09-19 (or later if Beta
slips). Frozen hosts should have no changes made to them without a
sign-off on the change from at least 2 sysadmin-main or rel-eng members,
along with (in most cases) a patch of the exact change to be made to
After I seen the talk about VDO:
I went ahead and tried it.
I tried it on small (12GB) sample of Copr data and I saved 20-30% data.
I then deployed it on production server retrace.fedoraproject.org and saved there 15% out of 2TB.
Several notes: The RPM packages are only available for RHEL. Recently the public github has been updated with version of
VDO, which should work on Fedora. No RPM available for Fedora yet though.
Here are my notes:
# vdo create --name=vdo1 --device=/dev/vdb --vdoLogicalSize=1T
# mkfs.ext4 /dev/mapper/vdo1
Some slides suggest to use -E discard. This is not needed for new volumes. See vdo-devel mailing list for reasoning.
# mount -o discard /dev/mapper/vdo1 /mnt/a
Probably best scenario is to create vdo on whole disk and then make PV from whole VDO disk and put LVM on top of that.
When you already have data, you cannot convert your disk to VDO. You need create new VDO disk, format it, mount it and
copy the data.
In my case, due limited space for migration I created a small LVM volume "vdosrv":
# lvcreate -L 80G -n vdosrv vol0
I converted it to VDO which claims to have 2TB of vitual total size
# vdo create --name=srv18 --device=/dev/vol0/vdosrv --vdoLogicalSize=2T
# mkfs.ext4 /dev/mapper/srv18
See how many space is *actually* free.
# mkdir /mnt/srv18
# mount -o discard /dev/mapper/srv18 /mnt/srv18
Now I moved some data from old volume to /mnt/srv18. I shrank the FS of old volume, I shrank the old LV. And then I
enlarged the new LV.
# lvresize -L +400G /dev/vol0/vdosrv
and let know vdo that it can use the new space:
# vdo growPhysical -n srv18
I repeated this several times.
I have to say that my experience is so far good.
I hope that my notes help someone.
Good Morning Everyone,
Our infrastructure is mostly a python store, meaning almost all our apps are
written in python and most using wsgi.
However in python we are using a number of framework:
* flask for most
* pyramid for some of the biggest (bodhi, FAS3)
* Django (askbot, Hyperkitty)
* TurboGears2 (fedora-packages)
* aiohttp (python3, async app: mdapi)
While this makes sometime things difficult, these are fairly standard framework
and most of our developers are able to help on all.
However, as I see us starting to look at JS for some of our apps (fedora-hubs,
wartaa...), I wonder if we could start the discussion early about the different
framework and eventually see if we can unify around one.
This would also allow those of us not familiar with any JS framework to look at
the recommended one instead of picking one up semi-randomly.
So has anyone experience with one or more JS framework? Do you have one that
would you recommend? Why?
Thanks for your inputs,
Here is the current agenda. Please update the gobby with items to be discussed.
This shared document is for the next fedora infrastructure meeting.
= Preamble =
The infrastructure team will be having its weekly meeting tomorrow,
2018-03-01 at 18:00 UTC in #fedora-meeting on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2018-03-01)
#chair smooge relrod nirik pingou puiterwijk tflink
= Let new people say hello =
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
= Status / Information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need
(Please use #info <the thing> - your name)
#topic announcements and information
#info Infrastructure hackfest in april:
#info The problem with 503's looks contained. Now they are 408s on the
server to look at
#info Rebuild mirrormanager container to be more resilient
#info Staging Koji synced with production - mizdebsk
#info New s390x builder in staging Koji, moved from prod - mizdebsk
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus /suor decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#topic Ticket cleanup
#info none this week.
= Apprentice office hours =
#topic Apprentice Open office minutes
#info A time where apprentices may ask for help or look at problems.
Here we will discuss any apprentice questions, try and match up people looking
for things to do with things to do, progress, testing anything like that.
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for
etc. Whoever would like to do this, just add the i/nfo in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
#topic Learn about:
#info none this week
= Meeting end stuff =
#topic Open Floor
Stephen J Smoogen.
The ability to move a repo to a new name in pagure would be useful.
This is currently not being worked on by anyone but pingou has volunteered
to review a patch if anyone submitted it.