Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.
Page 3 of 3 FirstFirst 123
Results 31 to 38 of 38

Thread: Cannot delete folder from' Delete folder' + various other small problems ...

  1. #31

    Title
    ViX Beta Tester
    Join Date
    Nov 2017
    Posts
    888
    Thanks
    103
    Thanked 480 Times in 285 Posts
    The especially odd thing about the background deletion is that it does an ltrunc on each file, shortening it by 20MB at a time until it has zero length. I just can't see how this can possibly be any more efficient or light on CPU than just removing the file's index entry with unlink. This has the smells of someone looking for a problem to apply a clever solution to. Now, if they'd commented it with workaround for unlink being slow across networks/due to a bug in drivers on Miraclebox 123 then we'd know where we were.

  2. The Following User Says Thank You to simonc For This Useful Post:

    Willo3092 (05-09-21)

  3. #32
    Valiant's Avatar
    Title
    Senior Member
    Join Date
    May 2016
    Posts
    144
    Thanks
    99
    Thanked 37 Times in 32 Posts
    Is there a comment/warning somewhere about recordings in progress/about to start? Would this be the reason why the the files are not removed by rm or unlink?
    VU+ Uno 4K SE Twin FBC Tuner 1TB HDD - Magic-FHD skin
    TV - LG OLED55CS6LA
    Remote - Logitech Harmony One

  4. #33

    Title
    ViX Beta Tester
    Join Date
    Nov 2017
    Posts
    888
    Thanks
    103
    Thanked 480 Times in 285 Posts
    You may be onto something; when you delete an in progress recording, it stops the timer, then tells the background deleter to remove the file. The recording code runs in a background thread, so it may not stop writing before the deleter starts. There's no useful comments to back this idea up though.

  5. #34

    Title
    ViX Beta Tester
    Join Date
    Nov 2017
    Posts
    888
    Thanks
    103
    Thanked 480 Times in 285 Posts
    PLi reckon it's because deleting large files on slow media can cause recording stutters. Probably related to the way Linux's ext filesystem organises the chunks of a large file.

    Found this on SuperUser
    When deleting a file, the ext3 filesystem will actually zero out the block pointers in the inode. The larger the file, the more blocks, and the more block pointers, thus the delete operation takes longer on larger files than smaller ones.


    This is different behavior than both ext2, which merely zeroes out the inode and leaves the blocks containing the block pointers intact (but marked as free) and ext4, which uses extents (and, since extents are a much more compact structure, has much better delete performance, that slows down based on how fragmented the file is, rather than how big it is).


  6. The Following User Says Thank You to simonc For This Useful Post:

    ccs (05-09-21)

  7. #35
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,771
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by BefuddledBrian View Post
    Linux has enough buffers to cope if a large deletion takes up to maybe around half a second.
    Deleting just removes the entries in the directory and frees the extents. It shouldn't take long, and not much I/O.
    I would think the only case that might take longer would be on some SSDs that have rather dumb implementations of TRIM, if TRIMming is done as the deletions are done.
    Only if you set the option, which isn't recommended. Better to run an fstrim once a week (which is effectively what MSWindows does too).
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  8. #36
    BrokenUnusableAccount

    Post

    Quote Originally Posted by birdman View Post
    Deleting just removes the entries in the directory and frees the extents. It shouldn't take long, and not much I/O.
    Only if you set the option, which isn't recommended. Better to run an fstrim once a week (which is effectively what MSWindows does too).
    My Windoze 7 PCs definately do TRIM as they delete. I notice that deleting larges files from my SSD lights the disk access light much longer than deleteing them from an HDD does.

  9. #37
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,771
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by BefuddledBrian View Post
    My Windoze 7 PCs definately do TRIM as they delete.
    Well, they do scheduled TRIMs too.
    Go to the disk/partition on file explorer, select Properties/Tools and click on Optimise. If you select to optimize an SSD it runs a TRIM on it. (My Windows partition currently says "OK (23 days since last retrim)". It's scheduled to run weekly (but I don't boot into Windows all that often, nor for very long).

    If it's TRIMming on each deletion as well then it's just wasting time and effort.

    "fsutil behavior query DisableDeleteNotify" does say that TRIM is enabled. Hmmm.....might help to explain some slow Windows actions. Might try changing it...
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  10. #38
    BrokenUnusableAccount

    Post

    Quote Originally Posted by birdman View Post
    Well, they do scheduled TRIMs too.
    Yes I think I remember seeing that Win 10 does scheduled TRIMs. But Win 7 doesn't, well not unless they hid it really well anyway.
    I don't know if Win 10 does TRIMs as it goes as well as scheduled.
    I assume a well designed modern SSD shouldn't slow anywhere near much as my old SATA ones do when TRIMming.

Page 3 of 3 FirstFirst 123

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.