| 13 Dec 2022 |
 GALLY | In reply to Victor Matheus
isso é uma opção permanente, ou tem que rodar de tempo em tempo pra ele percorrer tudo e fazer os links q puder? É um comando para se usar de tempos em tempos. Então, opção 2. | 15:33:55 |
 Lucas Eduardo | In reply to Victor Matheus
o q to pensando seria algo como ter
/nix/store
/nix/objects
sendo /nix/objects onde são dropados os arquivos reais, e aí o ostree vai jogando pra /nix/store/$hash conforme o caso (se novo, adiciona aos objetos, se conhecido, cria o link)
é assim q instalação/atualização de flatpak funciona No caso o nix deixa em /nix/store/.links | 15:34:28 |
 Victor Matheus | não tem nada q impeça de implementar o conceito em outros inits; mas pra ser consistente, tem que ser um init com "auto-governança" digamos assim, como o systemd | 15:35:06 |
| Lucas Eduardo | https://youtu.be/Z7p9-m4cimg | 15:47:59 |
 Erik | In reply to Victor Matheus
o q to pensando seria algo como ter
/nix/store
/nix/objects
sendo /nix/objects onde são dropados os arquivos reais, e aí o ostree vai jogando pra /nix/store/$hash conforme o caso (se novo, adiciona aos objetos, se conhecido, cria o link)
é assim q instalação/atualização de flatpak funciona O ostree n faz tudo com diff de binario, de forma incremental? Que eu me lembre ele funcionava com isso... | 16:10:59 |
| Erik | In reply to Erik
O ostree n faz tudo com diff de binario, de forma incremental? Que eu me lembre ele funcionava com isso... Sipa o nix faz a nivel de hash de arquivo, enquanto o ostree vai usar algo como o rsync, montando de forma incremental/delta cada arquivo. | 16:17:05 |
| Erik | Toda vez que tu apagasse uma geração antiga teria que refazer todos as geraçoes upstream | 16:20:13 |
| Lucas Eduardo | In reply to Erik
Sipa o nix faz a nivel de hash de arquivo, enquanto o ostree vai usar algo como o rsync, montando de forma incremental/delta cada arquivo. Isso deve gerar uma fragmentação desgracenta e só vai funcionar com uma performance decente em SSD | 16:33:58 |
 PedroHLC | In reply to Victor Matheus
pelo q entendi daí, sejam duas /nix/store/$hash diferentes, vc pode acabar com o mesmo exato arquivo armazenado duas vezes (uma lib por ex, se a compilação assim cria-las), sendo q poderia ser um hardlink Kkkkk vc pode sempre por a nix-store com dedup no ZFS | 16:44:03 |
| Victor Matheus | Mas a ideia do ostree é justamente usar full posix pra isso, sem depender de filesystem | 16:44:49 |
| Victor Matheus | Lembre q ele saiu de dentro da redhat, q não vai nem adotar openzfs, muito menos dar "aval" pra suse apoiando btrfs | 16:45:27 |
| Victor Matheus | Em vez disso tão empilhando lvm+xfs(stratus) +ostree+composefs (esse é novo) pra fazer tudo q btrfs/zfs se propõem, cp reflink+snapshot+dedup+verity | 16:46:54 |
| Victor Matheus | * Em vez disso tão empilhando lvm+xfs(stratis) +ostree+composefs (esse é novo) pra fazer tudo q btrfs/zfs se propõem, cp reflink+snapshot+dedup+verity | 16:47:06 |
| Victor Matheus | Eu acho maneiro pq vc pode pegar só uma parte dessa pilha q interesse, ao mesmo tempo em q a grana e devs da redhat seriam muito bem vindos no btrfs | 16:48:39 |
| Victor Matheus | In reply to Erik
Toda vez que tu apagasse uma geração antiga teria que refazer todos as geraçoes upstream Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto.
Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch.
Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. | 17:01:18 |
| Victor Matheus | * Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto.
Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch, dropar o arquivo novo em objects, e linkar pra branch q tá pedindo.
Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. | 17:02:11 |
| Lucas Eduardo | In reply to Victor Matheus
Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto.
Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch.
Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. Ele descarta na hora ou é que nem git que as vezes tem que rodar um git gc? | 17:04:17 |
| Victor Matheus | Não faço ideia. Mas eu esperaria algo automático baseado em tempo. Se não rolou um ostree-pull q reusou em xtempo, limpa.
Como ele é daemonless, deve verificar isso só quando vc faz alguma operação.
Claro, nada impede de uma implementação acima dele lidar com isso mais agressivamente, tipo o deb-ostree do endless, ou rpm-ostree dos fedora | 17:09:18 |
| Victor Matheus | O flatpak por ex mantém um.removed por um tempo, nunca monitorei quanto | 17:09:50 |
| Victor Matheus | Pelo menos a doc da cli do ostree é muito confusa e desatualizada, achei na doc comandos totalmente fora de ordem/q a cli disse pra mim q não existem | 17:14:14 |
| Erik | In reply to Victor Matheus
Pelo q entendi do ostree vc tem o objeto real, e todas as Nbranchs q tem links daquele objeto.
Uma mudança na branch q altere o objeto implica somente em desfazer o link naquela branch.
Quando não tem mais nenhum link pra um objeto, ele é descartado. Igual o .git/objects mesmo. hmmn, onde que entra a parte do "atomic"? | 17:21:02 |
| Victor Matheus | In reply to Erik
hmmn, onde que entra a parte do "atomic"? Ele troca o link, é uma operação só, ou tá linkado em oldfile, ou em newfile | 17:24:23 |
| Victor Matheus | Se for um arquivo novo, e não uma troca de arquivo, simplesmente criar o link. | 17:25:43 |
| Lucas Eduardo | eu to estudando uma forma de fazer isso ai só que multiplos discos | 18:21:15 |
| Victor Matheus | Btrfs faz isso aí, o cp no btrfs é um hardlink sempre q possível, cruzando discos.
Lvm + xfs vai ter isso tbm | 18:40:55 |
 Leonardo Neumann | In reply to Victor Matheus
Btrfs faz isso aí, o cp no btrfs é um hardlink sempre q possível, cruzando discos.
Lvm + xfs vai ter isso tbm Reflink você quis dizer | 19:57:59 |
| Leonardo Neumann | Que é o nome da cópia "deduplicada" do btrfs | 19:58:20 |
| Victor Matheus | No fim é um hardlink, só q direto no filesystem, não via vfs | 19:58:46 |
| Victor Matheus | O userspace só consegue descobrir se sair rodando stat em tudo e comparando até achar igualdade de inode | 20:00:06 |
| Leonardo Neumann | Sim, pode ser o mesmo inode, mas diferente de um hardlink isso não fica transparente a nível de filesystem | 20:00:35 |
