Limitations de l'Espace du Pool ?

[CorbeilleNews]

Bonjour,

J'aimerais partager avec vous mes investigations et hypothèses concernant un problème que j'ai sur un NAS et avoir vos avis :

Le problème :

Depuis que j'ai mis à jour une ancienne version de NAS4Free 9.0.2.1 vers XigmaNAS 12.0.0.4 puis 12.1.0.4 et fait l'upgrade des 2 Pools j'ai quelques soucis :

Dans un premier temps je n'arrivais pas à écrire ou modifier les fichiers sur les deux Pool mais à force de persévérence et de votre aide à travers plusieurs POSTS j'ai pu dans un second temps récupérer l'écriture partielle sur le second Pool puis sur le premier. (grâce à chmod et/ou suppression de fichiers aléatoirement possibles via navigateur et/ou webGUI : j'y reviens après car j'ai des doutes sur ce qui a aidé)

Vous allez me dire : OK donc tout va bien, et bien non car cela ne semble pas être si simple.

Le récapitiuliatif :

A l'origine j'utilisais OSX (Partages AFP) et une machine sous cette vieille version de NAS4Free et je n'avais aucun soucis pour remplir mes différents Pools. Au point de ne laisser que quelques méga d'espace disque restant (pas tapez svp ). J'avais activé également les partages respectifs en SMB pour d'autres périphériques pour lire les fichiers.

Au fur et à mesure du temps j'ai créé des nouveaux NAS sur de nouvelles machines (avec la version du moment de NAS4Free : j'ai donc un panachage de versions)

Alors qu'avec la 9.0.2.1 le webGUI et le finder indiquaient les mêmes espaces restant, l'écart entre ces deux méthodes différait de manière grandissante au fur et a mesure des itérations des firmwares : webGUI indiquant encore quelques Tera restant quand le finder indiquait presque zéro. Je me suis donc fié aux informations du Finder puisque c'est lui qui me limitait dans mes transferts et me suis dit que les espaces libres reportés dans le webGUI étaient mauvais.

Entre temps j'ai migré sous Linux et continué à utiliser les différents NAS tels que sans problèmes : remplissage possible au quasi maxi sur tous les NAS mais à l'aveugle car impossible de connaitre présicemment la taille restante des Pool puisque les webGUI des nouveaux NAS semblent indiquer des valeurs plus importantes que la réalité. De temps en temps je vérifiais sur OSX la taille restante pour me donner une idée ou alors si je voulais copier plus de données que disponible sur les NAS je me faisais refouler par Nautilus.

Enfin il y a peu j'ai fais la mise à jour du plus vieux NAS (sous 9.0.2.1) vers la 12.0.0.4 puis 12.1.0.4 puis upgrade des 2 Pools qu'il contient puisque tout "semblait" fonctionner.

Peu de temps après je suis m'apercu que je n'arrivait plus à écrire sur ces 2 Pools et avec votre aide j'ai tenté de faire un chmod -R 777 /mnt/monpool/ sur les deux Pools. Les partages AFP qui ne marchaint plus non plus et donc le reports des tailles disponibles et les modifs des fichiers sur OSX m'étaient impossibles. Cependant supprimer sur le second Pool restait une solution possible dans le webgui (incompréhensible car impossible dans nautilus).

Mon hypothèse :

La modification des droits (chmod) a t-elle permit de récupérer les possibilités d'écritures sur le second Pool ou est-ce plus a force de suppressions de fichiers (+ de 2 To) dans le premier Pool que j'ai pu recommencer à écrire des données dessus et à modifier les noms : si j'atteins la limite d'un peu moins de 2,2 To disponible dans le webGUI le système se rebloque (écriture impossible & suppression possible) puis se débloque (je peux tout faire) si je revide le Pool. Problème que je n'ai pas sur le second Pool ou du moins a une valeur limite de l'espace disque plus faible.

Le système (ZFS, XigmaNAS, Nautilus ?) semble se comporter comme s'il ne voulais pas que je descende en dessous d'un niveau d'espace disque libre pour modifier le Pool !!! (2,2 To pour le premier Pool et envion 1 To pour le second) Une sorte de limitation (c'est mon hypothèse) qui n'existait pas sur les versions précédentes (NAS4Free ou XigmaNAS je ne sais pas laquelle) qui empêche d'exploiter les 1 ou 2 derniers TeraOctets.

Je comprend que l'on doive laisser un peu d'espace disque inutilisé mais comment savoir ce qu'il reste puisque cette info est reportée différement selon la source et la version de NAS4Free/XigmaNAS. J'ai l'impression que d'avoir upgradé le firmware ou ZFS avec un Pool (trop) rempli m'a fait subir des limitations inexistantes avant upgrade et que c'est ce qui a bloqué mes deux Pools sur cette machine.

Après coup : jusqu'à ce que j'ai supprimé plus de 2 To de fichiers comment le système a t-il pu considérer qu'il n'y avait plus de place et m'empécher de réécrire le moindre octet si ce n'est une limitation "prévue" ?

J'aimerais me reconstituer un autre NAS pour tout y transférer les donnée dedans mais quelle version utiliser : la 9.0.2.1 qui fonctionnait très bien mais il faudra bien que j'ugrade un jour, avec le risque d'avoir à nouveau le même problème ...

Dernière question : peut-on upgrader le firmware du NAS sans upgrader le Pool afin de revenir à une version précédente si cela pose problème ?

[mtiburs]

Bonsoir,

C'est vrai que j'ai déjà constaté des tailles utilisées ou libres des fois "un peu étranges".

Pour les droits, je ne comprends pas toujours tout, l'autre fois j'ai du supprimer tous mes fichiers pour les remettre par le client lui-même (il y a certainement "des choses" à faire mais je ne m'en souviens jamais).

Pour les tailles:

Est-ce que tu peux faire ?:
zpool get all monpool
et çà :
zfs get all monpool

on peut des fois avoir une idée rien qu'avec çà

[mtiburs]

Ce qui aurait été bien, c'est d"avoir le résultat de ces commandes avant l'upgrade (pour comparer)

On peut imaginer que ZFS soit réglé différemment désormais, mais il est possible que certains paramètres jouent sur le calcul.
Je voudrais voir si la compression est activée.

Mais ce que je trouve étrange, c'est 2To ... çà me semble énorme

[CorbeilleNews]

Ce qui aurait été bien, c'est d"avoir le résultat de ces commandes avant l'upgrade (pour comparer)

On peut imaginer que ZFS soit réglé différemment désormais, mais il est possible que certains paramètres jouent sur le calcul.
Je voudrais voir si la compression est activée.

Mais ce que je trouve étrange, c'est 2To ... çà me semble énorme

Pour commencer merci d'avoir pris le temps de lire mon long post.

Qu'entendez vous par le "résultat des commandes" ? chmod ? Où trouver ce "résultat" ?

Je ne me souviens pas que les commades aient changé grand chose : beaucoup de fichiers dans de multiples dossiers et sous-dossiers sur des gros Pools et je n'ai pas vu beaucoup d'activité sur la led des disques voir quasiment aucune, sauf quand j'ai ajouter le "/" à la fin de la commande. D'ailleurs c'est pour cela que j'ai checher à connaître la syntaxe et le chemin exact cette absence d'activité pour autant de chose à faire m'avait paru bizarre ...

Bref sauf à essayer de reproduire le phénomène (ce dont je n'ai pas trop envie sur les autres NAS) cela semble difficile de localiser précisemment sa provenance.

Mais je suis comptant que 2 To vous paraisse, comme moi, beaucoup trop, sachant que c'est par Pool, et que je vasi avoir des NAS à upgrader dans l'avenir... C'est d'autant d'espace perdu utilisé ou utilisable avant upgrade.

Ou puis-je trouver si la compression est activée ou pas ?

Chose étrange depuis l'upgrade du firmware, après avoir lancé au moins une recherche d'un fichier avec nautilus, les recherches suivantes se faisaient désormais sans le réveil des disques et avec succès SVP... Je trouvais cela pas mal (bruit et consommation au top ), mais depuis que j'ai passé le cap des 2 To de libre à chaque recherche les disques se réveillent

Faudrait peut-être faire remonter ce genre de problème mais, où, à qui ?

[mtiburs]

J'avais marqué:
Est-ce que tu peux faire ?:
zpool get all monpool
et çà :
zfs get all monpool

N'ayant pas eu de réponse, je vais répéter:
Est-ce que vous pouvez faire ?:
zpool get all monpool
et çà :
zfs get all monpool
sur le pool actuel, car la compression y sera indiquée dans le résultat de la commande.

Je peux essayer de faire le test, çà ne me dérange pas de faire un pool avec une 9.x et ensuite de le passer en 11.x
Il faudrait, juste que je sache qu'elle genre de données c'est: des petits fichiers, moyens ou très gros ?

Avant de poser la question, il faut qu'on teste nous même et qu'on arrive à reproduire ce genre de chose

Mais j'aimerais bien voir le résultat tant demandé

[CorbeilleNews]

Désolé je n'avais pas vu la partie basse du message, j'ai mis ci dessous les résultats obtenus à travers le webgui

Concernant la réplication, la proportion des fichiers est la suivante (c'est à 90-95% des enregistrements de freebox dont les tailles sont très variables selon leur durée et leurs résolutions)

80% de 1-8 Go de MPEG4
10-15% de 10-30 Go de MPEG4
Quelques dizaines de giga de fichiers qui font quelques méga-octets
Quelques giga de fichiers qui font quelques centaines de kilo-octets


Voici le résulat de zpool get all monpool

NAME PROPERTY VALUE SOURCE
Pool0 size 65.2T -
Pool0 capacity 96% -
Pool0 altroot - default
Pool0 health ONLINE -
Pool0 guid 12553595716796921461 default
Pool0 version - default
Pool0 bootfs - default
Pool0 delegation on default
Pool0 autoreplace off default
Pool0 cachefile - default
Pool0 failmode wait default
Pool0 listsnapshots off default
Pool0 autoexpand on local
Pool0 dedupditto 0 default
Pool0 dedupratio 1.00x -
Pool0 free 2.04T -
Pool0 allocated 63.2T -
Pool0 readonly off -
Pool0 comment - default
Pool0 expandsize - -
Pool0 freeing 0 default
Pool0 fragmentation 1% -
Pool0 leaked 0 default
Pool0 bootsize - default
Pool0 checkpoint - -
Pool0 feature@async_destroy enabled local
Pool0 feature@empty_bpobj enabled local
Pool0 feature@lz4_compress active local
Pool0 feature@multi_vdev_crash_dump enabled local
Pool0 feature@spacemap_histogram active local
Pool0 feature@enabled_txg active local
Pool0 feature@hole_birth active local
Pool0 feature@extensible_dataset enabled local
Pool0 feature@embedded_data active local
Pool0 feature@bookmarks enabled local
Pool0 feature@filesystem_limits enabled local
Pool0 feature@large_blocks enabled local
Pool0 feature@large_dnode enabled local
Pool0 feature@sha512 enabled local
Pool0 feature@skein enabled local
Pool0 feature@device_removal enabled local
Pool0 feature@obsolete_counts enabled local
Pool0 feature@zpool_checkpoint enabled local
Pool0 feature@spacemap_v2 active local

Et les résultats de zfs get all monpool

NAME PROPERTY VALUE SOURCE
Pool0 type filesystem -
Pool0 creation Tue Aug 5 3:11 2014 -
Pool0 used 56.2T -
Pool0 available 5.00G -
Pool0 referenced 56.2T -
Pool0 compressratio 1.00x -
Pool0 mounted yes -
Pool0 quota none default
Pool0 reservation none default
Pool0 recordsize 128K default
Pool0 mountpoint /mnt/Pool0 local
Pool0 sharenfs off default
Pool0 checksum on default
Pool0 compression off default
Pool0 atime on default
Pool0 devices on default
Pool0 exec on default
Pool0 setuid on default
Pool0 readonly off default
Pool0 jailed off default
Pool0 snapdir hidden default
Pool0 aclmode discard default
Pool0 aclinherit restricted default
Pool0 createtxg 1 -
Pool0 canmount on default
Pool0 xattr off temporary
Pool0 copies 1 default
Pool0 version 5 -
Pool0 utf8only off -
Pool0 normalization none -
Pool0 casesensitivity sensitive -
Pool0 vscan off default
Pool0 nbmand off default
Pool0 sharesmb off default
Pool0 refquota none default
Pool0 refreservation none default
Pool0 guid 5727259284959765265 -
Pool0 primarycache all default
Pool0 secondarycache all default
Pool0 usedbysnapshots 0 -
Pool0 usedbydataset 56.2T -
Pool0 usedbychildren 122M -
Pool0 usedbyrefreservation 0 -
Pool0 logbias latency default
Pool0 dedup off default
Pool0 mlslabel -
Pool0 sync standard default
Pool0 dnodesize legacy default
Pool0 refcompressratio 1.00x -
Pool0 written 56.2T -
Pool0 logicalused 56.1T -
Pool0 logicalreferenced 56.1T -
Pool0 volmode default default
Pool0 filesystem_limit none default
Pool0 snapshot_limit none default
Pool0 filesystem_count none default
Pool0 snapshot_count none default
Pool0 redundant_metadata all default

[mtiburs]

Je ne vois d'anormal (je regardais surtout la compression si elle était activée, mais comme c'est du son et de la vidéo majoritairement, il ne faut surtout l'activer)

Pouvez-vous taper ceci:
nas1: ~# sysctl -a | grep "vfs.zfs.max_recordsize"

Pour info, moi, j'ai sur ce nas1 (12.0.0.4): vfs.zfs.max_recordsize: 1048576
soit un maximum de 128 To (1048576 X blocks-de-128Ko)

Je ne sais pas quoi dire de plus
Eventuellement, faire: sysctl -a | grep "zfs" (pour voir si il n'y a pas une valeur qui ferait une limite)

[mtiburs]

J'ai quand même l'impression que ZFS doit se mettre une certaine taille en réserve et il ne veut pas aller au delà d'une certaine limite
2To sur 65, ce n'est peut-être pas si "fou" que çà

Ce qui me chiffonne, c'est qu'il fait un calcul, et la valeur qui reste serait de 5Go

Pouvez-vous relire çà:
zfs get available monpool

et si, il y a toujours 5 Go, mettre un fichier de 4G dans le pool, et relire la valeur

si cette valeur passe à 1 Go, c'est qu'il existe bien une limite quelque part et quelle est bien gérée, mais je ne sais pas dans quelle valeur elle se situe (c'est peut-être une somme de paramètres qui fait la limite: une valeur restante + tous des bouts qui servent à ZFS, car il faut bien qu'il ait un peu d'espace pour se gérer, je penserais surtout au COW* par exemple)
*: COW=CopyOnWrite

et tous ces réglages peuvent être différents d'un ZFS à un autre

je vais essayer de retrouver une 9.x et faire des essais

[CorbeilleNews]

Je ne vois d'anormal (je regardais surtout la compression si elle était activée, mais comme c'est du son et de la vidéo majoritairement, il ne faut surtout l'activer)

Pouvez-vous taper ceci:
nas1: ~# sysctl -a | grep "vfs.zfs.max_recordsize"

Pour info, moi, j'ai sur ce nas1 (12.0.0.4): vfs.zfs.max_recordsize: 1048576
soit un maximum de 128 To (1048576 X blocks-de-128Ko)

Je ne sais pas quoi dire de plus
Eventuellement, faire: sysctl -a | grep "zfs" (pour voir si il n'y a pas une valeur qui ferait une limite)

Je ne sais pas ce que je dois exactement taper, car parfois il est ajouté des préfixes et/ou suffixes avant la ligne exacte que l'on doit taper donc dois-je mettre le tildé, le dièze et les guillemets ? Car si je tape exactement ~# sysctl -a | grep "vfs.zfs.max_recordsize" je n'ai rien d'autre comme résultat que $ # sysctl -a | grep "vfs.zfs.max_recordsize"

Pour le reste j'ai :

$ sysctl -a | grep "zfs"
z0xfffff8004b9d1200 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#2"];
<name>zfs::vdev</name>
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vol.immediate_write_sz: 32768
vfs.zfs.vol.unmap_sync_enabled: 0
vfs.zfs.vol.unmap_enabled: 1
vfs.zfs.vol.recursive: 0
vfs.zfs.vol.mode: 1
vfs.zfs.version.zpl: 5
vfs.zfs.version.spa: 5000
vfs.zfs.version.acl: 1
vfs.zfs.version.ioctl: 7
vfs.zfs.debug: 0
vfs.zfs.super_owner: 0
vfs.zfs.immediate_write_sz: 32768
vfs.zfs.sync_pass_rewrite: 2
vfs.zfs.sync_pass_dont_compress: 5
vfs.zfs.sync_pass_deferred_free: 2
vfs.zfs.zio.dva_throttle_enabled: 1
vfs.zfs.zio.exclude_metadata: 0
vfs.zfs.zio.use_uma: 1
vfs.zfs.zil_slog_bulk: 786432
vfs.zfs.zil_nocacheflush: 0
vfs.zfs.zil_replay_disable: 0
vfs.zfs.cache_flush_disable: 0
vfs.zfs.standard_sm_blksz: 131072
vfs.zfs.dtl_sm_blksz: 4096
vfs.zfs.min_auto_ashift: 12
vfs.zfs.max_auto_ashift: 13
vfs.zfs.vdev.trim_max_pending: 10000
vfs.zfs.vdev.bio_delete_disable: 0
vfs.zfs.vdev.bio_flush_disable: 0
vfs.zfs.vdev.def_queue_depth: 32
vfs.zfs.vdev.queue_depth_pct: 1000
vfs.zfs.vdev.write_gap_limit: 4096
vfs.zfs.vdev.read_gap_limit: 32768
vfs.zfs.vdev.aggregation_limit_non_rotating: 131072
vfs.zfs.vdev.aggregation_limit: 1048576
vfs.zfs.vdev.initializing_max_active: 1
vfs.zfs.vdev.initializing_min_active: 1
vfs.zfs.vdev.removal_max_active: 2
vfs.zfs.vdev.removal_min_active: 1
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.scrub_max_active: 2
vfs.zfs.vdev.scrub_min_active: 1
vfs.zfs.vdev.async_write_max_active: 10
vfs.zfs.vdev.async_write_min_active: 1
vfs.zfs.vdev.async_read_max_active: 3
vfs.zfs.vdev.async_read_min_active: 1
vfs.zfs.vdev.sync_write_max_active: 10
vfs.zfs.vdev.sync_write_min_active: 10
vfs.zfs.vdev.sync_read_max_active: 10
vfs.zfs.vdev.sync_read_min_active: 10
vfs.zfs.vdev.max_active: 1000
vfs.zfs.vdev.async_write_active_max_dirty_percent: 60
vfs.zfs.vdev.async_write_active_min_dirty_percent: 30
vfs.zfs.vdev.mirror.non_rotating_seek_inc: 1
vfs.zfs.vdev.mirror.non_rotating_inc: 0
vfs.zfs.vdev.mirror.rotating_seek_offset: 1048576
vfs.zfs.vdev.mirror.rotating_seek_inc: 5
vfs.zfs.vdev.mirror.rotating_inc: 0
vfs.zfs.vdev.trim_on_init: 1
vfs.zfs.vdev.cache.bshift: 16
vfs.zfs.vdev.cache.size: 0
vfs.zfs.vdev.cache.max: 16384
vfs.zfs.vdev.validate_skip: 0
vfs.zfs.vdev.max_ms_shift: 38
vfs.zfs.vdev.default_ms_shift: 29
vfs.zfs.vdev.max_ms_count_limit: 131072
vfs.zfs.vdev.min_ms_count: 16
vfs.zfs.vdev.max_ms_count: 200
vfs.zfs.txg.timeout: 5
vfs.zfs.space_map_ibs: 14
vfs.zfs.spa_allocators: 4
vfs.zfs.spa_min_slop: 134217728
vfs.zfs.spa_slop_shift: 5
vfs.zfs.spa_asize_inflation: 24
vfs.zfs.deadman_enabled: 1
vfs.zfs.deadman_checktime_ms: 5000
vfs.zfs.deadman_synctime_ms: 1000000
vfs.zfs.debugflags: 0
vfs.zfs.recover: 0
vfs.zfs.spa_load_verify_data: 1
vfs.zfs.spa_load_verify_metadata: 1
vfs.zfs.spa_load_verify_maxinflight: 10000
vfs.zfs.max_missing_tvds_scan: 0
vfs.zfs.max_missing_tvds_cachefile: 2
vfs.zfs.max_missing_tvds: 0
vfs.zfs.spa_load_print_vdev_tree: 0
vfs.zfs.ccw_retry_interval: 300
vfs.zfs.check_hostid: 1
vfs.zfs.mg_fragmentation_threshold: 85
vfs.zfs.mg_noalloc_threshold: 0
vfs.zfs.condense_pct: 200
vfs.zfs.metaslab_sm_blksz: 4096
vfs.zfs.metaslab.bias_enabled: 1
vfs.zfs.metaslab.lba_weighting_enabled: 1
vfs.zfs.metaslab.fragmentation_factor_enabled: 1
vfs.zfs.metaslab.preload_enabled: 1
vfs.zfs.metaslab.preload_limit: 3
vfs.zfs.metaslab.unload_delay: 8
vfs.zfs.metaslab.load_pct: 50
vfs.zfs.metaslab.min_alloc_size: 33554432
vfs.zfs.metaslab.df_free_pct: 4
vfs.zfs.metaslab.df_alloc_threshold: 131072
vfs.zfs.metaslab.debug_unload: 0
vfs.zfs.metaslab.debug_load: 0
vfs.zfs.metaslab.fragmentation_threshold: 70
vfs.zfs.metaslab.force_ganging: 16777217
vfs.zfs.free_bpobj_enabled: 1
vfs.zfs.free_max_blocks: 18446744073709551615
vfs.zfs.zfs_scan_checkpoint_interval: 7200
vfs.zfs.zfs_scan_legacy: 0
vfs.zfs.no_scrub_prefetch: 0
vfs.zfs.no_scrub_io: 0
vfs.zfs.resilver_min_time_ms: 3000
vfs.zfs.free_min_time_ms: 1000
vfs.zfs.scan_min_time_ms: 1000
vfs.zfs.scan_idle: 50
vfs.zfs.scrub_delay: 4
vfs.zfs.resilver_delay: 2
vfs.zfs.top_maxinflight: 32
vfs.zfs.zfetch.array_rd_sz: 1048576
vfs.zfs.zfetch.max_idistance: 67108864
vfs.zfs.zfetch.max_distance: 8388608
vfs.zfs.zfetch.min_sec_reap: 2
vfs.zfs.zfetch.max_streams: 8
vfs.zfs.prefetch_disable: 0
vfs.zfs.delay_scale: 500000
vfs.zfs.delay_min_dirty_percent: 60
vfs.zfs.dirty_data_sync_pct: 20
vfs.zfs.dirty_data_max_percent: 10
vfs.zfs.dirty_data_max_max: 4294967296
vfs.zfs.dirty_data_max: 3407353856
vfs.zfs.max_recordsize: 1048576
vfs.zfs.default_ibs: 17
vfs.zfs.default_bs: 9
vfs.zfs.send_holes_without_birth_time: 1
vfs.zfs.mdcomp_disable: 0
vfs.zfs.per_txg_dirty_frees_percent: 30
vfs.zfs.nopwrite_enabled: 1
vfs.zfs.dedup.prefetch: 1
vfs.zfs.dbuf_cache_lowater_pct: 10
vfs.zfs.dbuf_cache_hiwater_pct: 10
vfs.zfs.dbuf_metadata_cache_overflow: 0
vfs.zfs.dbuf_metadata_cache_shift: 6
vfs.zfs.dbuf_cache_shift: 5
vfs.zfs.dbuf_metadata_cache_max_bytes: 502047104
vfs.zfs.dbuf_cache_max_bytes: 1004094208
vfs.zfs.arc_min_prescient_prefetch_ms: 6
vfs.zfs.arc_min_prefetch_ms: 1
vfs.zfs.l2c_only_size: 0
vfs.zfs.mfu_ghost_data_esize: 24381227008
vfs.zfs.mfu_ghost_metadata_esize: 0
vfs.zfs.mfu_ghost_size: 24381227008
vfs.zfs.mfu_data_esize: 2019688448
vfs.zfs.mfu_metadata_esize: 58899456
vfs.zfs.mfu_size: 3721389568
vfs.zfs.mru_ghost_data_esize: 3535273984
vfs.zfs.mru_ghost_metadata_esize: 0
vfs.zfs.mru_ghost_size: 3535273984
vfs.zfs.mru_data_esize: 24092344320
vfs.zfs.mru_metadata_esize: 62496256
vfs.zfs.mru_size: 24253577216
vfs.zfs.anon_data_esize: 0
vfs.zfs.anon_metadata_esize: 0
vfs.zfs.anon_size: 65536
vfs.zfs.l2arc_norw: 1
vfs.zfs.l2arc_feed_again: 1
vfs.zfs.l2arc_noprefetch: 1
vfs.zfs.l2arc_feed_min_ms: 200
vfs.zfs.l2arc_feed_secs: 1
vfs.zfs.l2arc_headroom: 2
vfs.zfs.l2arc_write_boost: 8388608
vfs.zfs.l2arc_write_max: 8388608
vfs.zfs.arc_meta_strategy: 0
vfs.zfs.arc_meta_limit: 8032753664
vfs.zfs.arc_free_target: 172749
vfs.zfs.arc_kmem_cache_reap_retry_ms: 1000
vfs.zfs.compressed_arc_enabled: 1
vfs.zfs.arc_grow_retry: 60
vfs.zfs.arc_shrink_shift: 7
vfs.zfs.arc_average_blocksize: 8192
vfs.zfs.arc_no_grow_shift: 5
vfs.zfs.arc_min: 4016376832
vfs.zfs.arc_max: 32131014656
vfs.zfs.abd_chunk_size: 4096
vfs.zfs.abd_scatter_enabled: 1
kstat.zfs.misc.vdev_cache_stats.misses: 0
kstat.zfs.misc.vdev_cache_stats.hits: 0
kstat.zfs.misc.vdev_cache_stats.delegations: 0
kstat.zfs.misc.arcstats.demand_hit_prescient_prefetch: 0
kstat.zfs.misc.arcstats.demand_hit_predictive_prefetch: 934530
kstat.zfs.misc.arcstats.async_upgrade_sync: 4740
kstat.zfs.misc.arcstats.arc_meta_min: 2008188416
kstat.zfs.misc.arcstats.arc_meta_max: 924041000
kstat.zfs.misc.arcstats.arc_dnode_limit: 803275366
kstat.zfs.misc.arcstats.arc_meta_limit: 8032753664
kstat.zfs.misc.arcstats.arc_meta_used: 763674768
kstat.zfs.misc.arcstats.arc_prune: 0
kstat.zfs.misc.arcstats.arc_loaned_bytes: 0
kstat.zfs.misc.arcstats.arc_tempreserve: 0
kstat.zfs.misc.arcstats.arc_no_grow: 0
kstat.zfs.misc.arcstats.memory_available_bytes: 0
kstat.zfs.misc.arcstats.memory_free_bytes: 0
kstat.zfs.misc.arcstats.memory_all_bytes: 0
kstat.zfs.misc.arcstats.memory_indirect_count: 0
kstat.zfs.misc.arcstats.memory_direct_count: 0
kstat.zfs.misc.arcstats.memory_throttle_count: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0
kstat.zfs.misc.arcstats.l2_write_pios: 0
kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0
kstat.zfs.misc.arcstats.l2_write_full: 0
kstat.zfs.misc.arcstats.l2_write_not_cacheable: 18469
kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0
kstat.zfs.misc.arcstats.l2_write_in_l2: 0
kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0
kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0
kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0
kstat.zfs.misc.arcstats.l2_hdr_size: 0
kstat.zfs.misc.arcstats.l2_asize: 0
kstat.zfs.misc.arcstats.l2_size: 0
kstat.zfs.misc.arcstats.l2_io_error: 0
kstat.zfs.misc.arcstats.l2_cksum_bad: 0
kstat.zfs.misc.arcstats.l2_abort_lowmem: 0
kstat.zfs.misc.arcstats.l2_free_on_write: 0
kstat.zfs.misc.arcstats.l2_evict_l1cached: 0
kstat.zfs.misc.arcstats.l2_evict_reading: 0
kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0
kstat.zfs.misc.arcstats.l2_writes_lock_retry: 0
kstat.zfs.misc.arcstats.l2_writes_error: 0
kstat.zfs.misc.arcstats.l2_writes_done: 0
kstat.zfs.misc.arcstats.l2_writes_sent: 0
kstat.zfs.misc.arcstats.l2_write_bytes: 0
kstat.zfs.misc.arcstats.l2_read_bytes: 0
kstat.zfs.misc.arcstats.l2_rw_clash: 0
kstat.zfs.misc.arcstats.l2_feeds: 0
kstat.zfs.misc.arcstats.l2_misses: 0
kstat.zfs.misc.arcstats.l2_hits: 0
kstat.zfs.misc.arcstats.mfu_ghost_evictable_metadata: 0
kstat.zfs.misc.arcstats.mfu_ghost_evictable_data: 24381227008
kstat.zfs.misc.arcstats.mfu_ghost_size: 24381227008
kstat.zfs.misc.arcstats.mfu_evictable_metadata: 58899456
kstat.zfs.misc.arcstats.mfu_evictable_data: 2019688448
kstat.zfs.misc.arcstats.mfu_size: 3721389568
kstat.zfs.misc.arcstats.mru_ghost_evictable_metadata: 0
kstat.zfs.misc.arcstats.mru_ghost_evictable_data: 3535273984
kstat.zfs.misc.arcstats.mru_ghost_size: 3535273984
kstat.zfs.misc.arcstats.mru_evictable_metadata: 62496256
kstat.zfs.misc.arcstats.mru_evictable_data: 24092344320
kstat.zfs.misc.arcstats.mru_size: 24253577216
kstat.zfs.misc.arcstats.anon_evictable_metadata: 0
kstat.zfs.misc.arcstats.anon_evictable_data: 0
kstat.zfs.misc.arcstats.anon_size: 65536
kstat.zfs.misc.arcstats.other_size: 245811408
kstat.zfs.misc.arcstats.bonus_size: 58506560
kstat.zfs.misc.arcstats.dnode_size: 133461328
kstat.zfs.misc.arcstats.dbuf_size: 53843520
kstat.zfs.misc.arcstats.metadata_size: 392631296
kstat.zfs.misc.arcstats.data_size: 27582401024
kstat.zfs.misc.arcstats.hdr_size: 125232064
kstat.zfs.misc.arcstats.overhead_size: 945074688
kstat.zfs.misc.arcstats.uncompressed_size: 27551280640
kstat.zfs.misc.arcstats.compressed_size: 27029957632
kstat.zfs.misc.arcstats.size: 28346075792
kstat.zfs.misc.arcstats.c_max: 32131014656
kstat.zfs.misc.arcstats.c_min: 4016376832
kstat.zfs.misc.arcstats.c: 28591482512
kstat.zfs.misc.arcstats.p: 25318542995
kstat.zfs.misc.arcstats.hash_chain_max: 4
kstat.zfs.misc.arcstats.hash_chains: 25320
kstat.zfs.misc.arcstats.hash_collisions: 517100
kstat.zfs.misc.arcstats.hash_elements_max: 488542
kstat.zfs.misc.arcstats.hash_elements: 478806
kstat.zfs.misc.arcstats.evict_l2_skip: 0
kstat.zfs.misc.arcstats.evict_l2_ineligible: 2420507648
kstat.zfs.misc.arcstats.evict_l2_eligible: 201166362624
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_not_enough: 0
kstat.zfs.misc.arcstats.evict_skip: 22
kstat.zfs.misc.arcstats.access_skip: 66800649
kstat.zfs.misc.arcstats.mutex_miss: 126
kstat.zfs.misc.arcstats.deleted: 1279142
kstat.zfs.misc.arcstats.allocated: 33242344
kstat.zfs.misc.arcstats.mfu_ghost_hits: 7102
kstat.zfs.misc.arcstats.mfu_hits: 1368302208
kstat.zfs.misc.arcstats.mru_ghost_hits: 0
kstat.zfs.misc.arcstats.mru_hits: 7460258
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 17173
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 17011
kstat.zfs.misc.arcstats.prefetch_data_misses: 975700
kstat.zfs.misc.arcstats.prefetch_data_hits: 280898
kstat.zfs.misc.arcstats.demand_metadata_misses: 21594883
kstat.zfs.misc.arcstats.demand_metadata_hits: 1321855667
kstat.zfs.misc.arcstats.demand_data_misses: 31284
kstat.zfs.misc.arcstats.demand_data_hits: 53744893
kstat.zfs.misc.arcstats.misses: 22619040
kstat.zfs.misc.arcstats.hits: 1375898469
kstat.zfs.misc.zcompstats.skipped_insufficient_gain: 0
kstat.zfs.misc.zcompstats.empty: 16019
kstat.zfs.misc.zcompstats.attempts: 3607954
kstat.zfs.misc.zfetchstats.max_streams: 758072914
kstat.zfs.misc.zfetchstats.misses: 758272948
kstat.zfs.misc.zfetchstats.hits: 2548417
kstat.zfs.misc.xuio_stats.write_buf_nocopy: 0
kstat.zfs.misc.xuio_stats.write_buf_copied: 0
kstat.zfs.misc.xuio_stats.read_buf_nocopy: 0
kstat.zfs.misc.xuio_stats.read_buf_copied: 0
kstat.zfs.misc.xuio_stats.onloan_write_buf: 0
kstat.zfs.misc.xuio_stats.onloan_read_buf: 0
kstat.zfs.misc.abdstats.linear_data_size: 68148736
kstat.zfs.misc.abdstats.linear_cnt: 48765
kstat.zfs.misc.abdstats.scatter_chunk_waste: 21557760
kstat.zfs.misc.abdstats.scatter_data_size: 26961808896
kstat.zfs.misc.abdstats.scatter_cnt: 217057
kstat.zfs.misc.abdstats.struct_size: 61208192
kstat.zfs.misc.zio_trim.failed: 0
kstat.zfs.misc.zio_trim.unsupported: 2254
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.bytes: 0
security.jail.mount_zfs_allowed: 0
security.jail.param.allow.mount.zfs: 0

$ zfs get available Pool0
NAME PROPERTY VALUE SOURCE
Pool0 available 17.7G -

[mtiburs]

Bonjour,

Quand j'indique une commande, il ne faut pas taper le # (c'est juste pour montrer qu'on est dans l'invite de commande, connecté en root, d'oû le #).
Là je vais en mettre un peu plus:
root@superviseur:~# ssh root@192.168.1.197
root@192.168.1.197's password:
Last login: Mon Dec 9 02:15:13 2019 from 192.168.1.253
Welcome to XigmaNAS!
nas1: ~#
j'indique toujours la commande en gras (et c'est juste çà qu'il faut taper)

Une question:
Ce qui m'étonne, c'est que zfs get available Pool0 donne actuellement 17,7Go
Est-ce qu'entre les derniers posts, vous avez supprimé 12,7 To ?
Car le Pool0 est passé de 5 Go à 17,7 Go ! (je voudrais savoir si c'est de votre fait)

[CorbeilleNews]

J'ai ajouté et supprimé plusieurs giga mais pas des tera !

voici le résultat de :

$ sysctl -a | grep "vfs.zfs.max_recordsize"
vfs.zfs.max_recordsize: 1048576

[CorbeilleNews]

Je vais refabriquer un NAS pour transférer les données du gros Pool dans un Pool avec des disques moins nombreux mais avec plus d'espace histoire de repartir de zéro.

Cependant je ne sais pas quelle solution choisir :

Repartir sur une base NAS4Free 9.0.2.1 qui à priori me permet d'exploiter un plus grosse quantité d'espace disque (avec le risque d'avoir les mêmes problèmes lorsque j'updaterais un jour vers une version supérieure ou XigmaNAS), ou la dernière XigmaNAS, au moins je serais fixé d'emblée mais j'ai l'impression que les partages AFP ne fonctionnent pas comme ils fonctionnaient auparavant sous MAC.

J'ajoute que je constate sur d'autres NAS en version 10 et 11 qui semblent avoir les mêmes soucis : il reste entre 1 et 2 To d'espace disque libre dans le webgui et plus rien quand je veux écrire dessus (exemple je veux écrire quelques Go et Nautilus me dis qu'il manque juste un peu, si je libère de l'espace en supprimant des fichiers, je peux copier mes données : tout porte à croire que je suis au maxi je suis donc bien au maximum)

Avez-vous pu reproduire le problème de votre côté lors qu'n passage d'une 9 à 12 ?

Merci de votre aide.

[sleid]

download/file.php?id=7675&mode=view

[CorbeilleNews]

J'utilise l'accès invité car je n'y comprend rien à ces identifications, il faut créer des comptes et donner des autorisations et je mélange tout...

A quoi correspondent les paramètres additionels que vous avez mis ?

[sleid]

C'est la réponse donnée en exemple par ms49434 pour un partage AFP dans ce post
viewtopic.php?f=26&t=14677
Comme je n'ai pas de Mac pour tester, je ne peux vous aider plus mais une chose est certaine c'est que AFP fonctionne sur la v12