Re: [MooseFS-Users] converting to storage classes

[William K. <bi...@ii...>]

Thanks, this gives a way forward.

I'll use github in future - I wondered why the list wasn't very active!


BillK


On 24/2/21 7:27 pm, Agata Kruszona-Zawadzka wrote:
> W dniu 24.02.2021 o 00:15, William Kenworthy pisze:
>> Hi,
>
> Hi,
>
> I've answered your questions below, but please note, that we moved
> with support and troubleshooting to github and if you want to look up
> answers to similar problems, you should go there. Also, I would like
> to encourage you to ask your own questions on github in the future.
>
> https://github.com/moosefs/moosefs - main MooseFS repository.
>
> https://github.com/moosefs/moosefs/discussions - new feature on
> Github, discussions, this is where people ask questions.
>
>>      I have an approximately year old moosefs system with ~8GB data
>> (general data storage, email, lxc containers etc.) that was using
>> goal based allocation - I have added an ssd to and decided to use
>> storage classes to move one chunk of each of the lxc containers to
>> the faster SSD (seems to work well) while converting the the whole
>> storage to sclass based goal allocation.
>>
>> To convert I did a mfssetsclass -r at the top of the mfs tree - after
>> removing older snapshots (I have read an email on how they handle the
>> conversion) I am left with ~580000 still with a goal of 3 that is
>> reported by the cli.
>>
>> 1. how do I find which actual chunks are still at goal 3
>
> You can't find that out directly, but you can make an educated guess
> and say they all belong to snapshotted files. So if/when you remove
> snapshots, all remaining chunks will move to appropriate storage
> classes automatically.
>
>> 2. how can I map a chunk to a file
>
> There is not a simple way to find out and there is no tool for that.
> This is because of the system architecture - files know, which chunks
> belogn to them, but chunks do not know, to which file(s) they belong.
> It can be done, but it requires dumping all your metadata CHNK and
> EDGE sections to text format and manually searching for the chunk in
> question, then from EDGEs you can rebuild the whole path of the
> file(s). If you are really interested in that, I can write you a short
> "how to".
>
>> 3. I have used mfsmakesnapshot a bit indiscriminately and have likely
>> missed some snapshots - is there a way to identify chunks/files/dirs
>> belonging to a snapshot?
>
> Yes, there is. You go to the root of your MooseFS instance and use
> this command:
>
> mfsgeteattr *
>
> If you see any entry, that has "snapshot" written after its name and
> ":" sign, it's a snanpshot.
>
> To look deeper, you then use this command:
>
> mfsgeteattr -r *
>
> In the output, you look up all directories that have
>
> not directory nodes with attribute         snapshot :          XXX
> directories with attribute                 snapshot :          YYY
>
> where either XXX or YYY is something else than 0. This directory
> contains a snapshot somewhere inside it, so you cd into it and repeat
> the procedure.
>
>> The only way I can think of to remove unknown snapshotted data is to
>> copy the whole tree and delete the old one - which is a bit drastic!
>>
>> Is there another mechanism that prevents some chunks from being
>> converted to a storage class? - or am I reading this wrong?
>
> No, basically that's the only thing, that kind of "reverts to goal" -
> being part of a snapshot. All other chunks will be converted to a
> storage class (they still won't necessarily move to servers matching
> their storage class if something like lack of space or busy servers
> prevents this, but they will at least be trying to).
>
> Regards,
> Agata
>
> -- 
> Agata Kruszona-Zawadzka
> MooseFS Team