lkml.org 
[lkml]   [2015]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Tux3 Report: How fast can we fail?

    On 05/27/2015 04:04 PM, Austin S Hemmelgarn wrote:
    > On 2015-05-27 03:37, Mosis Tembo wrote:
    >>
    >> On 05/26/2015 12:03 PM, Pavel Machek wrote:
    >>>> We identified the following quality metrics for this algorithm:
    >>>>
    >>>> 1) Never fails to detect out of space in the front end.
    >>>> 2) Always fills a volume to 100% before reporting out of space.
    >>>> 3) Allows rm, rmdir and truncate even when a volume is full.
    >>
    >> This is definitely nonsense. You can not rm, rmdir and truncate
    >> when the volume is full. You will need a free space on disk to perform
    >> such operations. Do you know why?
    >>
    > I assume you are referring either to Tux3 specifically or COW
    > filesystems in general,


    I am referring to modern file systems with transaction models and
    delayed actions.
    Tux3 is not the case?


    > because you very much _can_ do any of those on any of the non-COW
    > filesystems in the Linux kernel


    It is simply incorrect. ReiserFS is a counterexample.


    > (I know from experience). Also, IIRC, it was mentioned somewhere that
    > Tux3 keeps a small reserve of space on the volume for internal
    > operations; and, I would assume that if that is the case, it reports
    > the volume full when everything *except* that reserve of space is
    > used, in which case rm, rmdir, and truncate should work fine when the
    > volume is full.


    Sorry, I prefer to not manipulate with rumors and assumptions when it comes
    to the review for kernel inclusion.

    Thanks,
    M.T.



    \
     
     \ /
      Last update: 2015-05-27 17:41    [W:4.040 / U:0.312 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site