Hi Greg,
just picked up this one from the archive while researching a different
issue and thought I'd follow up.
On Tue, Aug 19, 2014 at 6:24 PM, Gregory Farnum g...@inktank.com wrote:
The sst files are files used by leveldb to store its data; you cannot
remove them. Are you running on a very
I don't really know; Joao has handled all these cases. I *think* they've
been tied to a few bad versions of LevelDB, but I'm not certain. (There
were a number of discussions about it on the public mailing lists.)
-Greg
On Tuesday, September 16, 2014, Florian Haas flor...@hastexo.com wrote:
Hi
On 09/16/2014 04:35 PM, Gregory Farnum wrote:
I don't really know; Joao has handled all these cases. I *think* they've
been tied to a few bad versions of LevelDB, but I'm not certain. (There
were a number of discussions about it on the public mailing lists.)
-Greg
On Tuesday, September 16,
On Tue, Sep 16, 2014 at 6:15 PM, Joao Eduardo Luis
joao.l...@inktank.com wrote:
Forcing the monitor to compact on start and restarting the mon is the
current workaround for overgrown ssts. This happens on a regular basis with
some clusters and I've not been able to track down the source. It
The sst files are files used by leveldb to store its data; you cannot
remove them. Are you running on a very small VM? How much space are
the files taking up in aggregate?
Speaking generally, I think you should see something less than a GB
worth of data there, but some versions of leveldb under
Hello,
I’ve been testing cephfs with 1 monitor. My /var partition keeps on filling up
so that the mon process just die because of insufficient space. I drilled down
on /var partition that below mon path is taking most of the space with *.sst
files. I just curious what these files are and can
