Announcement

Collapse
No announcement yet.

What Was Said About EXT4 In Australia

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • What Was Said About EXT4 In Australia

    Phoronix: What Was Said About EXT4 In Australia

    Besides the Linux graphics stack being talked about this week at Linux.Conf.Au, there was also a talk by Ted Ts'o about the EXT4 file-system...

    http://www.phoronix.com/vr.php?view=OTA2MQ

  • #2
    One thing that really annoys me about EXT is the use of a percentage (5% IIRC) to reserve for root by default. Gets rather annoying when you are talking 100+ GB volumes.

    Comment


    • #3
      Originally posted by deanjo View Post
      One thing that really annoys me about EXT is the use of a percentage (5% IIRC) to reserve for root by default. Gets rather annoying when you are talking 100+ GB volumes.
      This is easily changeable during the creation process, and tweakable after the fact. The only thing standing in your way is having to unmount the filesystem to use tune2fs.

      mkfs.ext4 -m 0
      tune2fs -m 0

      Comment


      • #4
        The feature I wish had gone into ext4 is tail packing. I believe it may be the lack of this is one of the major causes of its relatively poor performance with lots of small files (e.g. the pacman package database).

        I guess I'll just have to wait of btrfs to stabilize. It has a lot of features I'm very enthusiastic about anyhow.

        Comment


        • #5
          Defragmenter is being worked on for how long? Beside that it should defragment automagically.

          Comment


          • #6
            Originally posted by edgan View Post
            This is easily changeable during the creation process, and tweakable after the fact. The only thing standing in your way is having to unmount the filesystem to use tune2fs.

            mkfs.ext4 -m 0
            tune2fs -m 0
            I realize that it is tweakable that is why I said "by default". It is just an extremely unreasonable default nowdays when we are dealing with huge volume size. It is as badly outdated as the "swap space should be double your ram" rule of thumb.

            Comment


            • #7
              To further expand on the "reserved for root" take an everyday 1 TB harddrive which are common as heck nowdays, that means by default it is going to reserve 50 Gigabytes and even setting it to one percent there is still an absurdly large amount of space used, 10 gigabytes when realistically a reserve capacity of 1 GB is still overkill. So you have either reserved 10 Gig minimum or none at all if you set it to 0%. You should be able to specify that size by an actual reserved size number instead of by percentage.

              Comment


              • #8
                Originally posted by deanjo View Post
                To further expand on the "reserved for root" take an everyday 1 TB harddrive which are common as heck nowdays, that means by default it is going to reserve 50 Gigabytes and even setting it to one percent there is still an absurdly large amount of space used, 10 gigabytes when realistically a reserve capacity of 1 GB is still overkill. So you have either reserved 10 Gig minimum or none at all if you set it to 0%. You should be able to specify that size by an actual reserved size number instead of by percentage.
                You may set the reserved blocks with "tune2fs -r" and reserve whatever size you want.
                However I agree that the default value should be tweaked.

                Comment


                • #9
                  Originally posted by edgan View Post
                  This is easily changeable during the creation process, and tweakable after the fact. The only thing standing in your way is having to unmount the filesystem to use tune2fs.

                  mkfs.ext4 -m 0
                  tune2fs -m 0
                  Actually, you don't even have to unmount

                  Comment


                  • #10
                    Oh come on, can't you at least summarize the video?

                    Comment


                    • #11
                      > Oh come on, can't you at least summarize the video?


                      Getting rid of spinlocks in the kernel VFS code can make your stuff go a lot faster if you have a crapload of fast disks and wide I/O pipe.

                      Comment


                      • #12
                        Originally posted by droidhacker View Post
                        Oh come on, can't you at least summarize the video?
                        Ok summary. Bunch of people worked on symetric multiprocessing from 2000 to 2004 since clock speeds stopped doubling. We about did all the coreing we can get away with since 8 core and maybe 16 core bulldozer and ivy bridge are going to completely run our ability to multiprocesses and multithread into a ditch. And IBM, INTEL, and everybody are going to try to jump start another frikkin manhatten project to expand the limits of our multiprocessing capability because you just don't frikkin count unless you need 12 million cores and want to run a monster cloud.
                        And blah blah blah table lock. Blah blah blah ext 4.
                        blah blah blah everybody pile on. Rip your goddamn hair out and put on a frikkin shackle and build the pharoh a tomb of gigantic core porportions. Then microsoft will try to steal it but since they are so frikkin retarded it took them windows 3.11 OS 2 1.0 1.1 and Windows 95 to figure out how to make a frikkin printer print something. They'll fail. But hopefully Apple will be smart enough to hijack it and mainstream it by giving you a little frikkin pad you can point at and drool and connect to the cloud.

                        I could be a raving frikkin lunatic. Or I could just be really aware of the situation we are in. You decide. Dial 1 985-655-2500 to vote no. Dial 1 SUC KIT IBM1 to vote yes. IBM would do it all themselves but since their company consists of 368,000 managers and 12,000 smart people that ain't going to happen.

                        http://www.youtube.com/watch?v=ltwxC19s5u8

                        Comment


                        • #13
                          Originally posted by drag View Post
                          >Getting rid of spinlocks in the kernel VFS code can make your stuff go a lot faster if you have a crapload of fast disks and wide I/O pipe.
                          ...and hang your lvm when you move a ext4 lv while doing heavy IO on it...
                          I do not really know if this is file system dependent, is somewhat hard to reproduce...

                          Comment

                          Working...
                          X