Re: Revert "dm space maps: don't reset space map allocation cursor when committing"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Yes, ramdisk itself is a thinly provisioned device. But We can't restrict what disks users use. So if disk doesn't support discard, it will cause this problem.
在 2022/3/2 0:06, Edward Thornber 写道:
I'm having trouble understanding your issue.  Does your ramdisk only allocate backing memory on demand?  (ie. is the ramdisk itself a thinly provisioned device?).  If so, not supporting discard seems to be the problem.

Thinp makes no promises about where it will allocate your data.  If you write a file, delete it, discard and then rewrite the file there is no guarantee that the file will be written to the same location.

On Tue, Mar 1, 2022 at 2:08 PM luomeng <luomeng12@xxxxxxxxxx <mailto:luomeng12@xxxxxxxxxx>> wrote:

    Because thin-pool is storage over-commitment, one of the following
    scenarios exists: constantly create and delete file, then the search
    doesn't hit the end of the metadata device, but ramdisk hits the end
    (not support discard). So the cursor doesn't reset.

    在 2022/2/28 23:37, Mike Snitzer 写道:
     > What you're saying doesn't make any sense.  Especially when you
     > consider this last part of the commit message:
     > "Fix these issues by leaving the cursor alone, only resetting
    when the
     >   search hits the end of the metadata device."


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux