Skip to content
This repository has been archived by the owner on Jan 13, 2022. It is now read-only.

Will it support TRIM operation? #192

Open
Kaydannik opened this issue Nov 7, 2014 · 13 comments
Open

Will it support TRIM operation? #192

Kaydannik opened this issue Nov 7, 2014 · 13 comments

Comments

@Kaydannik
Copy link

Hello.
I have Samsung 840 Pro 512GB.
During performance test with filesystem on it - it give me ~ 400 mb/s writes, and up to 15 000 iops.

But if i add it like a flashcache - speed is falling rapidly. Also writing/reading speed is not stable.
I already excluded all variants with dirty_thresh_pct and fallow_delay, etc..

Same performance issues i have if i use SSD with ext4 without discard option.

So, is any news/opportunities to support TRIM in flashcache ?
Thanks

@llcooljayr
Copy link

I tested Samsung 840 Evo 512GB with flashcache in raid setup and saw the same performance degradation. You might want to check with Samsung because they might have provided a firmware update for the Pro line since they provided a firmware update for the Evo which fixed an algorithm problem that address the dropped in performance. Also I don't think trim is supported by flashcache. In order to perform trim, the operating system, filesystem, ssd, and flashcache has to support it.

@mohans
Copy link
Contributor

mohans commented Nov 7, 2014

We have changes for TRIM support that will be committed shortly.


From: Kaydannik [email protected]
To: facebook/flashcache [email protected]
Sent: Friday, November 7, 2014 5:44 AM
Subject: [flashcache] Will it support TRIM operation? (#192)

Hello.
I have Samsung 840 Pro 512GB.
During performance test with filesystem on it - it give me ~ 400 mb/s writes, and up to 15 000 iops.
But if i add it like a flashcache - speed is falling rapidly. Also writing/reading speed is not stable.
I already excluded all variants with dirty_thresh_pct and fallow_delay, etc..
Same performance issues i have if i use SSD with ext4 without discard option.
So, is any news/opportunities to support TRIM in flashcache ?
Thanks

Reply to this email directly or view it on GitHub.

@Kaydannik
Copy link
Author

Awesome! champagne is prepared!

@rferris
Copy link

rferris commented Nov 19, 2014

I'm so excite!

@Kaydannik
Copy link
Author

@mohans Hi. Any news with TRIM ? Is project is in development ?

@mohans
Copy link
Contributor

mohans commented May 14, 2015

Unfortunately, all new development on flashcache is on hold now (except for any critical fixes). Too busy working on other things :(, will revisit the trim support later this year as time permits.

@ghost
Copy link

ghost commented May 19, 2015

Hi,
I'm looking at the code trying to find place for TRIM.
And I'm curious if putting ioctl(device, BLKDISCARD, &range); in flashcache_subr.c:flashcache_invalid_remove() is enough?

@ghost
Copy link

ghost commented May 19, 2015

Sorry, my mistake, not flashcache_invalid_remove(), but flashcache_invalid_insert().

@ghost
Copy link

ghost commented Jun 22, 2015

https://github.com/sphdev/flashcache/commit/76b44f1c62f902f51261da44cb98398df868175c
Trying to add TRIM support.
Still not sure if it's enough.

@ghost
Copy link

ghost commented Jun 23, 2015

Another interesting place for TRIM could be flashcache_hash_remove()
Just thinking how many places like this exist and which one is the best for TRIM command. Any ideas?
https://github.com/sphdev/flashcache/commit/94ae1cd614b12c371d2cc5404a7892662f8ccc92

@ghost
Copy link

ghost commented Jul 13, 2015

I've been trying to implement support for FITRIM.
I'm using Debian, my partition is formated as XFS. So I've started with checking, why FITRIM is not passed.
In flashcache_conf.c in function flashcache_ctr() I've added two lines:
ti->discards_supported = 1;
ti->num_discard_requests = SOMEVALUE; // I have no idea what should be there
With those 2 lines FITRIM in XFS is passed. But...
The problem is kernel panic that occurred during flashcache_map() in flashcache_main.c.
This function is calling flashcache_do_block_checks().
Inside we have:
VERIFY(to_sector(bio->bi_size) <= dmc->block_size);
And the problem is to_sector(bio->bi_size), because it's too high. In my situation it's 2280560 and dmc->block_size is 8.
Does anyone have any idea how to solve this problem?

My test looks like this:
#flashcache_load /dev/sdb
#mount /dev/mapper/fcache /mnt
#fstrim /mnt
(kernel panic)

@mohans
Copy link
Contributor

mohans commented Jul 13, 2015

You need a lot more changes for TRIM that those changes in _conf.c.
TRIM is still a work in progress. We have patches (not committed) that discard TRIM'ed blocks from the cache, but those patches do not yet send the TRIMs down to the cache drive.
We have been pulled to work on other things, so don't know when those patches will be committed.
mohan
From: sphdev [email protected]
To: facebook/flashcache [email protected]
Cc: Mohan Srinivasan [email protected]
Sent: Monday, July 13, 2015 2:00 AM
Subject: Re: [flashcache] Will it support TRIM operation? (#192)

I've been trying to implement support for FITRIM.
I'm using Debian, my partition is formated as XFS. So I've started with checking, why FITRIM is not passed.
In flashcache_conf.c in function flashcache_ctr() I've added two lines:
ti->discards_supported = 1;
ti->num_discard_requests = SOMEVALUE; // I have no idea what should be there
With those 2 lines FITRIM in XFS is passed. But...
The problem is kernel panic that occurred during flashcache_map() in flashcache_main.c.
This function is calling flashcache_do_block_checks().
Inside we have:
VERIFY(to_sector(bio->bi_size) <= dmc->block_size);
And the problem is to_sector(bio->bi_size), because it's too high. In my situation it's 2280560 and dmc->block_size is 8.
Does anyone have any idea how to solve this problem?My test looks like this:
#flashcache_load /dev/sdb
#mount /dev/mapper/fcache /mnt
#fstrim /mnt
(kernel panic)—
Reply to this email directly or view it on GitHub.

@ghost
Copy link

ghost commented Jul 14, 2015

Is there any way to see those patches?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants