Écrire directement dans l'adresse du disque dur sous Windows 7
Bonjour,
je cherche à écrire directement à une adresse bien précise dans le disque dur comment pourrais-je m'y prendre sous Windows 7 ? je dois simuler un programme qui nécessite beaucoup de RAM, n'en ayant pas assez je préfère assigner tout le rôle de RAM à mon disque dur. Le programme en question va massivement aller d'adresse en adresse, je ne peux donc pas écrire dans des fichiers car les rechercher d'abord dans la table prendrait un temps énorme en plus de celui de l'accès au disque.
Bonjour,
je vois pas pourquoi ce serait lent en passant par la fat, et en écrivant dans un gros fichier.
En mode administrateur, on peut travailler hors fat, et lire/écrire des secteurs partout sur le disque, avec les fonctions de l'api Windows :
HANDLE hdl = CreateFileA(disk_name);
SetFilePointer(hdl, num_secteur*size_sector);
ReadFile(hdl, buf, n*size_sector);
WriteFile(hdl, buf, n*size_sector);
CloseHandle(hdl);
Beaucoup de ram à simuler c'est combien ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
12 go de RAM.
satinas, selon moi pour avoir accès à un fichier il faut d'abord avoir son nom puis le chercher dans la table pour savoir à quelle adresse le trouver est-ce bien ça ?
Ce ne serait pas plus rapide d'écrire dans une clé USB ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Achète de la mémoire.Envoyé par Computer Mail
Sauf que les mécanismes de cache de l'OS font que c'est globalement très rapide. Idem pour ce que tu veux faire.
A moins de savoir exactement ce que tu veux faire, tu as de très bonnes chances d'être moins efficace pour plus d'efforts et plus de risques.
Contourner la gestion du système de fichier était une technique utilisée par les bases de données pour gagner du temps. Aujourd'hui, on y recourt largement moins.
Salut,
Excuses si je suis bouché, mais j'ai rien compris à ton affaire, tu veux scanner ton disque ?
Tu veux trouver un fichier sur ton disque?
C'est quoi une adresse précise ?
Si je ne me trompe pas, le disque est organisé en blocs de 4096 octets, tu veux lire ces blocs ou écrire dans des blocs
dans ce cas, regarde les API qui permettent de lire des blocs, de les charger en mémoire, de les remettre sur le disque etc..
Comme je ne sais pas ce que tu veux réellement faire, je souhaite tous de même te faire remarquer que l'écriture directe dans des blocs sur le disque présente des risques sérieux.
Cordialement
Ludwig
PS:
Ces API existaient par le passé, je ne sais pas si c'est toujours le cas, quelqu'un confirmera ou infirmera.
Y-a-t'il un avantage à utiliser une clé USB plutôt qu'un disque dur ?
C'est que ce n'est pas quelques fichiers que mon programme comportera mais plusieurs dizaines de millions, si je dois chercher dans une table avec autant d'éléments ça va commencer à prendre du temps.
Ludwig1 c'est ça, je veux écrire et lire à une adresse précise du disque dur, plus clairement dans la plus petite unité https://fr.wikipedia.org/wiki/Secteur_de_disque sans me soucier d'un quelconque système de fichier.
Compte tenu des risques d'erreurs dans la mise au point du programme ce n'est à faire que sur un support dédié qui ne contient rien d'autre.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Je plussois, d'autant que prendre ce risque est inutile.
Si vous vous focalisez sur la vitesse de lecture du disque, alors je pense que vous raisonnez mal.
Ce n'est pas la latence de lecture du disque qu pose problème, mais peut-être les données...
Si vous compressez les données avant de les stoquer sur le disque, vous avez moins de données à lire, ce qui accélère la lecture.
Et si le processeur est rapide, le temps de décompression qui s'ajoute donc à celui de la lecture, donne un temps de lecture "net" si j'ose dire, plus court qu'une lecture "normale" des données non compressées.
Tout dépend de la vitesse de lecture du disque et de la vitesse du processeur.
Maintenant, par experience, avec un PC moderne (processeur rapide), la compression me semble avantageuse.
Ici, avec les éléments que vous nous donnez, on ne peut pas dire si cette méthode est meilleure (puisque la réduction de la taille à la compression dépend des données), par contre je vous suggère de l'essayer avant de prendre le risque de flinguer l'OS en vous trompant à l'écriture sur un secteur (même un bug qui ne serait pas en rapport avec une erreur algorithmique peut vous amener à écrire sur le mauvais disque/secteur).
Pourquoi des millions de fichiers, et pas un seul gros fichier ?
Ce qui est une aberration. Cela veut dire qu'il y a une erreur de conception.
On parle de fichier mais ce n'est pas du tout ça qui sera traité dans le programme. C'est plus des paquets de 64 bits (64 à chaque secteur) et dans ces 64 bits aucun nom d'un quelconque fichier et aussi vous l'imaginez bien il n'est pas question de compresser quoi que ce soit là dedans. Le temps de latence d'un disque dur est au mieux de 100ms, le débit avoisine quelque 100mo/s, je dois à chaque lecture d'un nouveau secteur ajouter un temps d'accès, vous le voyez là aussi que le temps d'accès est énorme dans mon programme.
Le problème, ce n'est pas qu'on n'a pas compris ce que tu veux faire.
C'est qu'on sait pourquoi ce n'est pas efficace et risqué mais que tu refuses de l'entendre.
De plus, tu cherches une solution compliquée et inefficace dans laquelle tu ne vas pas utiliser assez de mémoire et tu cites des chiffres de disque dur classique, très lent et inadapté quand un SSD serait largement devant.
On te répète que construire toi même une pelleteuse pour creuser un trou dans ton mur afin de mettre une cheville et une vis est surdimensionné, dangereux, etc. Tu nous répètes à quelle point la pelleteuse est une bonne idée.
si tu veux pouvoire espérer gagner du temps, ce n'est pas 64 octets à la fois qu'il faut lire/écrire, mais au moins 512.
Ensuite pour améliorer encore la vitesse, il faut utiliser le cache du disque en question.
Comme dit plus haut, tu ne gagneras pas en performances en court-circuitant ton OS ( pas de manière significative en tout cas)
les vitesses de lecture/écriture sur un disque, même un SSD sont extrêmement lentes comparé aux accès à la RAM
Il vaut mieux investir dans 12Go de ram supplémentaire..
J'avais raté ça. En effet. Avec une transition vers un secteur de physique de 4k qui est en cours : https://support.microsoft.com/en-us/...ves-in-windows
Salut,
J'ai fait un petit tour dans mes archives,
Alors voila,
Les disques sont gérés par un circuit intégré spécialisé, en général plus complexe qu'un processeur. Tu peux descendre jusqu'à ce niveau si tu le souhaites, mais ça suppose que tu devras écrire tes procédures en langage machine. Evidement à ce stade rien n'est formaté, tu dois tous gérer, mais alors vraiment tout, positionnement des winchester etc... etc... Je ne connais pas ton niveau, mais ayant eu à calculer par le passé (époque héroïque de la TTL) des algorithmes d'accès disques le chef ( DT CII HB ) nous faisais remarquer qu'on usait le soleil quand c'était pas assez rapide. Ceci pour l'anecdote.
Ce que je ne comprend pas bien c'est la raison pour laquelle tu ne veux pas utiliser les outils classiques qui fonctionnent, charger un bloc en mémoire, le cas échéant analyse de ce bloc etc...
De toute façon tes données sont enregistrées selon le protocole résident de ton système d'exploitation. Si vraiment tu veux toucher à tous ça, alors suit le conseil de JPL, met sur une clé USB et entraine-toi la dessus.
Puis dans un an tu nous dira ou t'en est.
Je t'ai mis un peu de lecture ici http://www.hddzone.com/fr/ ça te permettras de te faire une idée du comment tout ça ça fonctionne.
Encore une fois, le bios est imposé, si tu veux court-circuiter ça et que tu saches vraiment écrire du code machine, t'en a pour au moins un an avant que quelque chose ne fonctionne si jamais.
Cordialement
Ludwig
J'ai un disque SSHD avec des secteurs physiques de 4096 octets, et Windows 10 à jour me renvoie toujours une taille de secteur de 512 octets. Bizarre, d'après ce que je lis, il est censé les prendre en charge sans émulation 512 octets. C'est peut être ma version de Qt qui n'est pas à jour.
Ok, c'est parce que le bios est paramétré en mode Legacy, pas UEFI.
Si la méthode classique va directement à l'adresse souhaitée et ne passe pas d'abord par une recherche dans la table et qu'elle me permet dans un secteur d'utiliser pour mon programme absolument tous les bits qui s'y trouvent (sans utiliser un deuxième secteur bien évidement) je n'ai rien contre.
Oui le disque dur est géré par un circuit imprimé mais je n'ai en rien besoin de connaître sa composition détaillée, les interruptions matérielles jouent un rôle ici non ?
Je ne l'avais pas dit, le programme est en c++.
Le problème d'un disque dur c'est qu'il s'agit ... d'un disque.
Lorsque la donnée suivante ne se trouve pas à la suite de celle déjà lue (secteur suivant), entendu la tête de lecture n'a pas eu le temps de se positionner sur la piste de la donnée suivante, la lecture doit attendre que le disque fasse un tour suplémentaire (de manière très schématique sans rentrer dans le détail du cache).
C'est la raison pour laquelle les defragmenteurs de disque positionnent les fragments de FICHIERS de manière intelligente, à la suite les uns des autres (ce qui n'est pas une opération aussi évidente qu'il n'y parait...) et donc ce positionnement augmente les performances de lecture.
De la même manière pour l'écriture (qui entre en conflit avec la lecture.. ou pas)
Ici, avec les éléments minimalistes que vous nous fournissez, il n'est pas possible de vous conseiller une méthode ou quoi que ce soit.
Je vous fais simplement remarquer que la lecture d'un fichier compressé (par exemple, cas banal) à 90% vous permet de lire 10x plus de données en une seule fois, alors qu'en non compressé il vous faut 10x plus de temps (et bien plus si vous prenez en compte la question de la fragmentation).
Bien sur, si vous ne pouvez pas faire autrement que de stoquer 64 groupes de 64 octets sur chaque secteur, sans qu'ils n'aient aucun rapport entre eux et que vous ne pouvez pas prévoir lesquels seront nécessaire (dans quel ordre) au traitement programmatique, la compression n'est pas intéressante (plus le fichier est gros et mieux il se compresse, en général)
Après, à moins que l'ordre de lecture des données soit totalement aléatoire, je doute qu'il n'y ait pas moyen de regrouper les groupes de 64 octets intelligemment. Dans ce cas, peut-être que le stoquage des ces données sous forme d'enregistrement dans une base de données pourrait régler l'affaire. (d'autant que là aussi, les requêtes stoquées permettent une accélération des accès)
Il est justement question de ça, ceci répond t'il à ma demande https://support.microsoft.com/en-us/...ss-under-win32 ?
Ça me fait penser à une expérience de jeunesse il y a plus de 20 ans, où on m'avait demandé de concevoir un programme pour crypter la FAT avec un bête algorithme XOR. J'avais tenté le truc, mais avec le manque de moyen qu'un étudiant en informatique avait à l'époque, j'avais tenté ça sur mon unique disque dur (qui contenait le système évidemment).
Après un échec total à mon premier essai (disque dur complètement planté), j'avais utilisé un logiciel pour voir l'état de ma FAT en héxadécimal, et j'avais retrouvé des bouts de mon code source écrit dans la FAT
Ca m'avait quand même fait rire malgré la nécessité de réinstaller tout (pas très lourd sur un disque dur de 20Mo...).
Si vous voulez absolument essayer cette méthode, faites-le, mais comme déjà dit il existe des moyens plus standard pour gérer une banque de données.
Ici, dans votre cas (64 octets de données) vous avez typiquement affaire à des "enregistrements".
Or les systèmes de gestion de base données sont OPTIMISES pour le traitement des gros volumes (12 GB est géré sans problème) ainsi qu'à l'accés ultra-rapide aux enregistrements.
Je serais donc pas étonné qu'un Mysql sous apache, que de nombreux experts ont mis au point pendant de nombreuses années, soit bien plus performant au traitement demandé qu'un montage maison que vous ne serez jamais en mesure d'optimiser pleinement (et encore, si vous y parvenez vous ne l'aurez fait que pour la configuration matérielle et logicielle particulière que vous employez actuellement)
Salut,
Il me semble qu'on t'as déjà dit ça https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
d'autant plus que tu programme en CPP
Cordialement
Ludwig
Re,
Ramasse tes blocs dans la mémoire RAM pour analyse, tu peux alors même faire des dump mémoire si t'as envie de voir ce qu'il y a dedans.
Cordialement
Ludwig
Voilà en tous cas le support le plus approprié, la RAM.
RAM c'est Random Access Memory et comme son nom l'indique c'est le support physique dédié aux données dont l'acces est "Aléatoire".
Le disque dur n'est pas fait pour stoquer des octets (64 octets c'est presque la même chose) qui peuvent être lus aléatoirement.
S'il n'y a aucun ordre de classement (des octets à la suite dans un fichier, c'est déja un classement), ça ne peut que faire mouliner le disque et franchement je ne sais pas si, à terme, les aller-retours de la tête de lecture ne risquent pas de provoquer une usure prématurée du disque.
Pur portnawak.
Dans ce contexte, random ne signifie pas aléatoire mais direct, par opposition historique a séquentiel.
Nous sommes ici dans un cas de logique Shadock appliquée a l'IT ....
On a beaucoup expliqué mais quand la personne ne veut pas comprendre ni même écouter que faire ?
Il y a une phrase célèbre sur "même les dieux luttent en vain".
