This discussion is archived
4 Replies Latest reply: Aug 7, 2013 10:35 AM by Dude! Branched from an earlier discussion. RSS

Re: Is it possible to a new-clean install oracle linux 6.4 onto btrfs partition

ne1 Newbie
Currently Being Moderated

I thought I would first just hijack someone else's forum thread for my question.

But since I was not helping that other original poster,

and since my "issue" has NOTHING to do with that other forum thread,

and I wanted everyone's attention on me instead of what was covered in that thread,

a kind forum moderator has split my inquiry away to let it stand on its own.


So ...


In trying the Oracle Linux Release 6 Update 4 utilizing the UEK Boot ISO image I was not able to get it to work.  I used the distribution mentioned above:


https://edelivery.oracle.com/EPD/Download/get_form?egroup_aru_number=16064752

 

Oracle Linux Release 6 Update 4 Media Pack for x86_64 (64 bit)                   V37084-01        3.5G

Oracle Linux Release 6 Update 4 UEK Boot ISO image for x86_64 (64 bit)      V37090-01      196M

 

The approach I used with VirtualBox 4.2.16 was the one described in the Readme for Media Pack B72263-01 titled "Installing Oracle Linux using the Unbreakable Enterprise Kernel" (the second section of the README).

 

The procedure in a nutshell to install Oracle Linux 6 Update 4 with btrfs root filesystem:

  • Extract all of V37084-01 (OL6U4 ISO) to web docroot folder
  • Remove "images" folder from web docroot folder
  • Extract "images" folder from V37090-01 (UEK BOOT ISO) to web docroot folder
  • Boot from V37090-01 with "askmethod" boot option
  • Point installation to web docroot folder over HTTP

 

Results:

  • During the installation process the root filesystem was listed as btrfs (good)
  • The askmethod URL process was able to connect to the web server and grab install.img (good)
  • Got an error trying to get repomd.xml - exact error text was:

 

Unable to read package metadata. This may be due to a

missing repodata directory. Please ensure that your install

tree has been correctly generated.

 

Cannot retrieve repository metadata (repomd.xml) for

repository: anaconda-

OracleLinuxServer-201302251439.x86_64. Please verify its

path and try again


Here's the entries from the web server access log:

192.168.1.102 - - [28/Jul/2013:21:00:08 -0700] "GET /uek6u4/images/install.img HTTP/1.1" 200 133201920

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/.treeinfo HTTP/1.1" 200 1546

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/.treeinfo HTTP/1.1" 200 1546

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/UEK2/.treeinfo HTTP/1.1" 404 219

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/UEK2/treeinfo HTTP/1.1" 404 218

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/repodata/repomd.xml HTTP/1.1" 404 224

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/UEK2/repodata/repomd.xml HTTP/1.1" 200 3100

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/UEK2/repodata/e242ac8afc8845ecb24ec3be38a5439042a8511ad26ce838f7f93ca9b49a33e5-primary.sqlite.bz2 HTTP/1.1" 404 302

192.168.1.102 - - [28/Jul/2013:21:01:22 -0700] "GET /uek6u4/repodata/repomd.xml HTTP/1.1" 404 224

192.168.1.102 - - [28/Jul/2013:21:01:23 -0700] "GET /uek6u4/repodata/repomd.xml HTTP/1.1" 404 224

 

It looks to me like maybe the install tree in the Oracle Linux 6 Update 4 distribution with the btrfs root filesystem option just needs to be re-generated.

 

Any help would be appreciated.

 

Thanks.


  • 1. Re: Is it possible to a new-clean install oracle linux 6.4 onto btrfs partition
    ne1 Newbie
    Currently Being Moderated

    I guess I didn't explain my "issue" very well since someone apparently thought it had "nothing" to do with the original question but actually the original question - "is it possible to [achieve] a new-clean install of oracle linux 6.4 onto a btrfs partition" - is what both the original poster and I are trying to achieve.  Well, I guess technically it might be - "is it possible to achieve a new-clean install of oracle linux 6.4 with a btrfs root filesystem" - but that's how I interpreted the original poster's question (since btrfs is a filesystem and not disk partitioning software).

     

    I guess to help the original poster the answer is "yes, it is possible to complete a new, clean install of oracle linux 6.4 with a btrfs root filesystem", at least in theory (accepting that the root "/" filesystem and the boot "/boot" filesystem are different).  The documentation lays it out in reasonably good detail however my "issue" was that in following the UEK6u4 README instructions I ran into technical difficulty.  I tried to include a reasonable amount of context and technical detail in hopes that someone might recognize that uek6u4 with the UEK Boot ISO installing into a btrfs root filesystem needed help.  I used exactly the same ISO files that GlennD referenced from edelivery and mentioned their Oracle part numbers for clarity.  I paraphrased the README instructions as I understood them so that my process could be understood.  I listed the error I ran into (cannot retrieve repomd.xml) and finally the lines from the network installation web server log to illustrate that the network installation portion was successfully communicating with the web server and finding some but not all of the components it was looking for.  For example, from the web server log it looks like the installer is trying to "GET /uek6u4/repodata/repomd.xml HTTP/1.1" (returned 404 - not found) but the V37084-01 OL6U4 ISO has a "repodata" FILE (zero bytes) rather than a DIRECTORY with a repomd.xml file in it. 


    In searching through the distribution tree it seems that there are many repomd.xml files throughout the tree, here's what I found searching from the root of the OL6U4 ISO -

     

    DIR  ./HighAvailability/repodata/

    FILE ./HighAvailability/repodata/1309c71722bd4fee8c7f33b43b346800340d6a62159112c83056bac7ccf674ab

    FILE ./HighAvailability/repodata/1c33a7bd0e6d0a0c1fc08a566a9f0d15d5b6323c9c5f9b0c14dd46953df8896d

    FILE ./HighAvailability/repodata/2ae2772083e8ae96b26fb7b9c871a5a0ea988308ad91a1918744986ba200c4aa

    FILE ./HighAvailability/repodata/4bf4039fbd4ace1bf7b3ebd1ad7257266d63982266f3131783dee512efe537d7

    FILE ./HighAvailability/repodata/783b0606db60868031cc3c8607aac5cc9552dc3fd19f520292c4521ca9fb8e8f

    FILE ./HighAvailability/repodata/7dbdd8ac41d851cec2ae59fd918638712b4c3c01b5f5c7c86fe40768ca65e543

    FILE ./HighAvailability/repodata/9569223dbb4981873e3866d49da5724d7c6cee99e916f67d79eebc30956b3286

    FILE ./HighAvailability/repodata/97e906bea827160308f8b5efefee0b6697752daadd1a3f412773cea9a732e7db

    FILE ./HighAvailability/repodata/repomd.xml

    FILE ./HighAvailability/repodata/TRANS.TBL

    DIR  ./LoadBalancer/repodata/

    FILE ./LoadBalancer/repodata/1bca4ff9ef7f8bfe0d22c8c80c285277db5b9a5206d7d45b1bb3e8d88ce6bb15

    FILE ./LoadBalancer/repodata/2b2dac323d5dfe687aef018df0c63ebafefb50bb5eb6086507a429045f71745a

    FILE ./LoadBalancer/repodata/3cf4b2d7f9122de838135bdd03ab54b0a0b508a28dc76d3af2f7da0cbef6a3ae

    FILE ./LoadBalancer/repodata/4652516e959c98b4ad040cf7a832798f826d02b8cb8a9d3dccb7effd0b2704d7

    FILE ./LoadBalancer/repodata/4aefc4aa913a34061baa0d07f29c8e771dbb270ee71e25951b549e27a2048731

    FILE ./LoadBalancer/repodata/783713693126d2cd54a9132e95d80add961fba0548f3386c480eaee7a36bfa2f

    FILE ./LoadBalancer/repodata/c1486b0598280960ec912cd5659d2f4251a37bc3ea002012d614969ad659f867

    FILE ./LoadBalancer/repodata/e3fd7ebdc8f4e1cfff7f16aaaa9ffcf6f11075bffdac180f47780bbc239c5379

    FILE ./LoadBalancer/repodata/repomd.xml

    FILE ./LoadBalancer/repodata/TRANS.TBL

    FILE ./repodata  <== shouldn't this be a DIR with 10 files in it?

    DIR  ./ResilientStorage/repodata/

    FILE ./ResilientStorage/repodata/226b626658f3372f6080990a7257f59ed395e008e553698db03f5909eed0a7ec

    FILE ./ResilientStorage/repodata/45a8c1daa560cf6a2e47a2d1bbb65cc4c7eb02018dd102981778c1b6fe8faf6e

    FILE ./ResilientStorage/repodata/895ecb501c4ac6275c527b09c2515ade5280b4765e67652a6a0cd72e97c8eb70

    FILE ./ResilientStorage/repodata/afdb31804a1b2cf232612d28222bdbbde8841f88fdabc2374a7b074c8728d4cb

    FILE ./ResilientStorage/repodata/b36b9a83448c498146c8379d55d60ba6b7b480687508e9c0f77dff7892bfa0e9

    FILE ./ResilientStorage/repodata/c0e99334320e08437cde4838921ecb89d72e04d5a5c10c3975b7e7b7ceb93bf6

    FILE ./ResilientStorage/repodata/ecfe2dbeb8351517658ec0c2bd08260375b2b39dd12cee346cfa7674bc2eb3c7

    FILE ./ResilientStorage/repodata/fb9f6c12954b27b1c21facecf0521b0885404046d8de89f43d040a8928304c3e

    FILE ./ResilientStorage/repodata/repomd.xml

    FILE ./ResilientStorage/repodata/TRANS.TBL

    DIR  ./ScalableFileSystem/repodata/

    FILE ./ScalableFileSystem/repodata/15f83344887c89c2455260a1fae8df74cf14a70562f3dd67ff736015779ae3a4

    FILE ./ScalableFileSystem/repodata/304cdf8c9616b1145d83b1b98d40c56869f7fd06252f933c58f87a8fe8253aca

    FILE ./ScalableFileSystem/repodata/47db77be275bd88275ce9defd2ee4c8175acb02eea9ea4e738099d9067b67123

    FILE ./ScalableFileSystem/repodata/4ab14e6695cf0860414c571a219022e55db3fb3841c26f39676fb84dc51beefd

    FILE ./ScalableFileSystem/repodata/62c7919eeef1323253efc65e6a7c1925df2db8789685ef5472975db91e1a9daf

    FILE ./ScalableFileSystem/repodata/6c210eb621f2c6eecbd5735b08aac6fd333d49988bc33c3782300c1ee42e664b

    FILE ./ScalableFileSystem/repodata/a0c3770da1fa5040b475d851a0f12c994319b9013f8e9b149373545fd41d5ccf

    FILE ./ScalableFileSystem/repodata/e77a303c23c291110cf81120f63056148d133a4fc0bb10b3df2b4828394017a9

    FILE ./ScalableFileSystem/repodata/repomd.xml

    FILE ./ScalableFileSystem/repodata/TRANS.TBL

    DIR  ./Server/repodata/

    FILE ./Server/repodata/0be33010a8f4a5dba47c01ff076d0496a4769183f38408ed129d8aaa5f5892e8

    FILE ./Server/repodata/1128d65ff56fccb8a939df7dc75f03014ddf7bd81c2c91300d5a4271ec785be4

    FILE ./Server/repodata/3b01cde7260a69b90c5f432a38341b09c42d4837efee07c8ce31630cfad7475b

    FILE ./Server/repodata/5ecdce130bb8ecdf6fcc93b545611142eaa791c71d34c0fc8efc374965f81ab9

    FILE ./Server/repodata/6697b4e8eca0ce6e764c1832920a975a80c7d166cef307bffa90667b4bc810a0

    FILE ./Server/repodata/9a3e0233455b3ecedd93172bcfc95a292d6f10f63794501c0f4533d953808a1c

    FILE ./Server/repodata/eaacfe95bd9353e47f4433cc6f5813c5930b25379f3ffcfc5bfabc27b1554ece

    FILE ./Server/repodata/f834646271812927300b1edf3df3041b84766e8b09564e43647cee006ac7ed4d

    FILE ./Server/repodata/repomd.xml

    FILE ./Server/repodata/TRANS.TBL

    DIR  ./UEK2/repodata/

    FILE ./UEK2/repodata/254f490ef3e04f595e0771554f0422a9700d82ec65620096a43a0887ea531efa

    FILE ./UEK2/repodata/766365cf674b18ccc0f0030259bc8e1ccf39505121139926dbc0bc81c5bbe5d5

    FILE ./UEK2/repodata/88918db74ae976cd4d38625873b5def58388ec71d208714a903e72f92e72589a

    FILE ./UEK2/repodata/a542e9e5609df3469bcefc45ad8e720e82d923295b2eaae933807e803cfa2e86

    FILE ./UEK2/repodata/bff6bfe6e45a09fd3304b504a1a99a145bf6601330567c80090fba717a606aaa

    FILE ./UEK2/repodata/e242ac8afc8845ecb24ec3be38a5439042a8511ad26ce838f7f93ca9b49a33e5

    FILE ./UEK2/repodata/repomd.xml

    FILE ./UEK2/repodata/TRANS.TBL


    I appreciate the forum help in splitting me off into a separate thread, I just hope someone fixes the UEK6u4/UEK6u4 Boot ISO images as the btrfs filesystem looks very interesting and I imagine there's lots of people that would like to learn more about it through direct experience.  I know I would.

     

    Thanks.

  • 2. Re: Is it possible to a new-clean install oracle linux 6.4 onto btrfs partition
    Dude! Guru
    Currently Being Moderated

    I think the instructions to setup a BTRFS root system requiring a network based install are probably too advanced for simply evaluating how BTRFS works. You might also want to keep in mind, that BTRFS is great for redundancy and data snapshot recovery, but it is not suitable for Oracle database files, or files subject to high I/O and data modification, at least not without a performance and space managment penalty.

     

    If you perform a new installation, I'd rather suggest the following installation strategy: Install Oracle Linux booting from the standard distribution DVD. Do not use the default installation, but edit the partition layout manually. Remove the LVM volumes and create standard ext4 partitions instead. You will need a /boot partition and a root partition (/), and of course a swap partition. There is no need to get too fancy on partitioning beyond the default 3 partitions, at least not for testing.

     

    The /boot partition, which stores the 2nd stage of the boot loader and the Linux system startup image cannot be BTRFS, because the Grub boot loader of RHEL or OL cannot read BTRFS. The root partition (/) can be BTRFS if you use the latest UEK or UEK2 kernel. After you have installed the OS, you can boot the system using the UEK boot image and convert the ext4 root partition to BTRFS. You need to boot from external media to convert the root partition.

     

    I looked into BTRFS last year and created some instructions. Unfortunately, the content is a bit messed up now due to the recent forum software update, and I don't know if there are errors or even nonsense now, but perhaps you find the following info useful:

     

     

    HOWTO: Converting LVM root to BtrFS in Oracle Linux 6

    Re: btrfs root filesystem

  • 3. Re: Is it possible to a new-clean install oracle linux 6.4 onto btrfs partition
    ne1 Newbie
    Currently Being Moderated

    Dude wrote:

     

    I think the instructions to setup a BTRFS root system requiring a network based install are probably too advanced for simply evaluating how BTRFS works.

    Actually the instructions in the README on the eDelivery site for OL6 Update 4 were very easy to follow and made complete sense.  I'll admit setting up an HTTP server and navigating the networking could be challenging but these are aspects I happen to be familiar with so it worked out well.

     

    The problem seems pretty clear that the OL6 Update 4 ISO files are not put together correctly with respect to the "repodata" files/directories.  The installer retrieved many files successfully (HTTP and network working ok) but failed when it tried to GET repodata/repomd.xml.  Looking at the ISO structure there is a file named repodata and not a directory named repodata with a file named repomd.xml inside of it.  This data structure seems to be repeated throughout the distribution in various sub-directories; all the sub-directories seems to be constructed as the installer expects except for the one at the "top" of the distribution where there is just a zero byte file named repodata instead of the expected directory named repodata.

     

    I was hoping to catch someone's attention that could either fix the ISO's on eDelivery or provide instructions, similar to the "images" instructions in the README, which would allow the repodata data structures to be corrected manually.  I'd be happy to follow any manual instructions.

     

    My thought/concern with the "convert ext4 root filesystem to btrfs" approach is around the difference between an initial clean install and a retrofitted/converted install.  It might be a bit of a "purist" perspective but given that I'm investigating something new that I'm unfamiliar with my preference is to have as few "extra" variables involved as possible.  I understand that btrfs will snapshot the existing root ext4 filesystem and then only read from those blocks (traversing btrfs structures to get to them) but write all modified blocks to new, btrfs-managed blocks.  However, my assumption is that the converted filesystem data structures on disk could very likely look significantly different than a btrfs-created, clean filesystem.  (It's the same type of thought process that leads people to want to do clean installations of new desktop operating systems rather than convert/upgrade them in-place for example.)

    If you perform a new installation, I'd rather suggest the following installation strategy: Install Oracle Linux booting from the standard distribution DVD. Do not use the default installation, but edit the partition layout manually. Remove the LVM volumes and create standard ext4 partitions instead. You will need a /boot partition and a root partition (/), and of course a swap partition. There is no need to get too fancy on partitioning beyond the default 3 partitions, at least not for testing.

    Thanks for your advice on eliminating the LVM - in light of zfs filesystems being positioned as a logical volume manager and filesystem combined I was wondering if btrfs was intended to take on the same role.  The zfs filesystem is very impressive but given its licensing "difficulties" I thought it best to gravitate towards btrfs (similar technological advances with no licensing hurdles).  It's my understanding that they are somewhat similar in vision and given btrfs's volume manager-like capabilities (various levels of RAID, etc) it seemed like an extra layer of complexity to use it on top of LVM.

     

    I assume that btrfs is suitable for files subject to high I/O and data modification without performance and space management penalties, although I have gotten some mixed signals, especially on the space management front.  One of the aspects of btrfs that attracted me was it's high performance.  I watched and read several of Avi Miller and Chris Mason's presentations that made the case for btrfs as a high performance filesystem with very significantly faster I/O performance than ext4, xfs, etc.  He showed several graphs comparing the various popular filesystems with btrfs and how it's superior design allowed it to outperform the competition.  As for space management, one aspect of btrfs that really caught my attention was how "old" blocks ever get reused.  I get the copy-on-write thing and it sounds good, making snapshots possible, etc., but in all the presentations I didn't understand how "old" blocks were ever retired.  On the surface it sounds like btrfs filesystems just continually consume storage until finally they run out - and there might not be any files left in the filesystem!  For example, if one were to create/write-a-block/remove a file in a loop eventually all storage would be consumed with most/all of it locked up with blocks that were part of files that had long since been removed. 

     

    Really appreciate you taking the time ...

     

    Thanks.

  • 4. Re: Is it possible to a new-clean install oracle linux 6.4 onto btrfs partition
    Dude! Guru
    Currently Being Moderated

    What presentation or graphs have you seen? If Btrfs is indeed so much faster, I wonder what ext4 is doing wrong? Btrfs is apparently work in progress and what was said about performance yesterday may no longer be valid tomorrow. Regarding high performance I/O and space management, perhaps you will find Re: Btrfs nodatacow interesting.

     

    I can imagine that working with large caches, or SSD disks, may eliminate a great deal of the COW technology overhead, as I/O performance does not rely on physical head movement and read ahead buffering used by conventional hard drives. However, according to my last information, Btrfs is not supported or recommended for Oracle database files. Re: Looking for a filesystem for OLTP DB Workload on OEL6

     

    About your concern with converting an ext4 partition to Btrfs vs. a clean install, sorry, I don't know. I don't think it will affect performance or function.