1. OCAU Merchandise now available! Check out our 20th Anniversary Mugs, Classic Logo Shirts and much more! Discussion here.
    Dismiss Notice

disk io dies when deleting a file?

Discussion in 'Other Operating Systems' started by Dutch Wink, Jul 18, 2010.

  1. Dutch Wink

    Dutch Wink Member

    Joined:
    Aug 21, 2001
    Messages:
    2,096
    Location:
    Perth 6020
    Or more accurately - stops serving a file from a hard drive while deleting a large file from a completely unrelated hard drive? Once the delete is done, everything is normal again.

    We're talking sata2 disks, and streaming an mp3 over the network so not exactly a demanding load. running debian lenny x64 on a c2d with 2gb ram, no swapfile.

    I figure I just need to fiddle with some kernel settings, but, which?

    Current settings I've tried over time which vastly improved performance (for copying large files) over a default install, but still not perfect:

    vm.swappiness = 5
    vm.vfs_cache_pressure = 50
    vm.dirty_background_ratio = 15
    vm.dirty_ratio = 30
     
  2. the-enigma

    the-enigma Member

    Joined:
    Mar 18, 2002
    Messages:
    1,728
    Location:
    BrisVegas
    What filesystem(s)?
     
  3. OP
    OP
    Dutch Wink

    Dutch Wink Member

    Joined:
    Aug 21, 2001
    Messages:
    2,096
    Location:
    Perth 6020
    ext3 on all
     
  4. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    41,023
    Location:
    Brisbane
    How large is said "large file"?

    EXT3 is god-awful for large file deletion. I've yet to find any way of dealing with it.
     
  5. HyRax1

    HyRax1 ¡Viva la Resolutión!

    Joined:
    Jun 28, 2001
    Messages:
    7,911
    Location:
    At a desk
    Do you have AHCI enabled in your BIOS? This makes disk I/O all the more efficient and gets you back some CPU time from reduced overhead too.

    And yes, get rid of EXT3.
     
  6. OP
    OP
    Dutch Wink

    Dutch Wink Member

    Joined:
    Aug 21, 2001
    Messages:
    2,096
    Location:
    Perth 6020
    CPU time shouldn't be the issue - plenty to spare, it's only running a vbox vm fulltime on one of the two cores.

    Can't recall if ahci is on or not.

    Large file = 4gb plus. dvd isos and backup tarballs. What filesystem would you guys suggest for relatively few files and dirs (couple hundred tops), almost all multiple gb in size?

    But still, what baffles me is that the kernel (?) is stopping all read activites on an otherwise idle disk, while a delete operation goes on somewhere else entirely. I have this inkling that a simple fs change won't fix it since it shouldn't be the cause... happy to learn how/why tho.


    :)
     
  7. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    41,023
    Location:
    Brisbane
    XFS is designed specifically for this.

    ext3's implementation is to lock all activity on a file unlink until all inodes are removed. I have no idea why (file system programming is way beyond my knowledge), but it's certainly been like that as far back as I can remember (including back to ext2).
     
  8. grs1961

    grs1961 Member

    Joined:
    Jan 21, 2005
    Messages:
    506
    Location:
    Melbourne
    Just to re-iterate, XFS was designed for this. (I used to work at SGI, doing QA on XFS. And XFS doesn't have the problem explained below.)

    And to confirm this - a lot of the Linux internals have been implemented using a "one big lock" model: whenever something critical or dangerous is being done, stop all access to that. (This seems to be because a lot of Linux developers aren't really trained systems programmers, so they often use simplistic solutions (cf. Linux Threads prior to NPTL) because "better" solutions are outside their knowledge. (Of course, some of them know more about the bits they work on than anyone else on the planet!!!))

    Ext4 is supposed to not have this problem. For that matter, neither should murderFS (aka ReiserFS), BtrFS, or JFS.
     
  9. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    41,023
    Location:
    Brisbane
    A big "thank you" from me from the TV, film, and VFX (Visual Effects) industries as a whole. XFS is the saviour of that industry, and the sysadmins who work in it. :):thumbup:
     
  10. foxmulder881

    foxmulder881 Member

    Joined:
    Nov 17, 2004
    Messages:
    5,884
    Location:
    Gold Coast, QLD OS:Linux
    And welcome back for elvis. :thumbup::D:thumbup:
     
  11. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    41,023
    Location:
    Brisbane
    The ext4/BtrFS bit is good news.

    If BtrFS and GRUB 2 can also eliminate the need for DOS-style partitions, I might actually enjoy working with Linux storage again.

    Cheers. :)
     
  12. CoolBlade

    CoolBlade Member

    Joined:
    Jul 31, 2001
    Messages:
    152
    Location:
    Brisbane
    What do you mean 'dos' style partitioning?

    If you're serious about partitioning issues then use LVM.
     
  13. foxmulder881

    foxmulder881 Member

    Joined:
    Nov 17, 2004
    Messages:
    5,884
    Location:
    Gold Coast, QLD OS:Linux
    Elaborate more on dos style partitioning. Linux partitioning is as flexible as ever and as flexible as you want it to be. :confused:
     
  14. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    41,023
    Location:
    Brisbane
    Many proprietary UNIX systems these days allow LVM direct on physical disks with no partitions, and allow booting from there.

    Linux and GRUB still require /boot to be on a legacy partition (aka "/dev/sda1", or equivalent). With GRUB 2 you can put /boot on LVM, but the PV itself must still be inside a partition. The downside there is that whatever your first physical disk, you are always forced to use partitions on it because /boot is in a partition.

    What I want is, under Linux, to be able to use a PV with LVM on the entire device, without partitions for ALL parts of the OS (not just non-boot data drives). This is still a major downfall to Linux and GRUB currently.

    I already use PVs on bare disks today, but they can't be /boot. Why does this suck?

    1) On my laptop, I have one hard disk. This forces me to use partitions on the entire disk due to /boot being on that disk

    2) I build a server with 8 identical hard disks. I want to use all 8 hard disks in a Linux sofware RAID6 with LVM over the top. I can't. I need to either waste a disk (or two, for RAID) with partitions and have my PVs on the other 6 over bare disk, or I need to use partitions to boot from, forcing partitions over the rest of the disks (and when I'm over 6TB in space, that means GPT).

    3) On my home file server, I have 4 disks - 2 RAID1 sets. While the non-boot set is Linux RAID on bare disk (no partitions), with LVM straight on the bare disk, the disks that contain /boot are forced to use partitions for everything else too (i.e.: half of my non-OS data, as it spans across the two RAID sets).

    They are getting closer and closer, but it's still not close enough. I want to abolish DOS-style partitions entirely from a Linux system and run 100% from LVM. It's a legacy thing that IMHO should have been eradicated years ago.

    (And check the sticky in this forum and the user who wrote all the information about LVM - I know it quite well :)).

    Partitioning is nowhere near as flexible as LVM. Add to that the upper bounds of standard partitions (and the need for GPT) and you hit another wall.

    I want to see the death of partitions. LVM on bare disk is what I want. Partitions merely get in the way.
     
    Last edited: Jul 20, 2010

Share This Page

Advertisement: