Instalar Steam
iniciar sesión
|
idioma
简体中文 (Chino simplificado)
繁體中文 (Chino tradicional)
日本語 (Japonés)
한국어 (Coreano)
ไทย (Tailandés)
български (Búlgaro)
Čeština (Checo)
Dansk (Danés)
Deutsch (Alemán)
English (Inglés)
Español - España
Ελληνικά (Griego)
Français (Francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (Húngaro)
Nederlands (Holandés)
Norsk (Noruego)
Polski (Polaco)
Português (Portugués de Portugal)
Português - Brasil (Portugués - Brasil)
Română (Rumano)
Русский (Ruso)
Suomi (Finés)
Svenska (Sueco)
Türkçe (Turco)
Tiếng Việt (Vietnamita)
Українська (Ucraniano)
Informar de un error de traducción
Normas y directrices sobre discusión
11 
Denunciar este mensaje
https://www.tomshardware.com/pc-components/hdds/seagates-fraudulent-hard-drives-scandal-deepens-as-clues-point-at-chinese-chia-mining-farms
Those Barracudas were even recertified ones and they are running 24/7 for 3,5 years now without any issues. Im also saving two bays on my NAS and ready for future upgrades. Never going below 24tb again.
I had many drives over the years and Seagate never ceases to satisfy. Ive had dying WD Red Pros and Toshiba Enterprises and whatnot, but never a Seagate. Call it a fluke or whatever, but thats just my 2 cents.
The Seagate lacks quality and is rather slow when compared to my old western digital that comes encased in helium and has a large 512mb cache.
The Seagate is only rated for 190mb/sec. My old western digital can sustain over 300mb/sec and is close to SATA SSD speeds. It's the only HDD I have that can play starfield.
Skyrim players.
i have a pair of 4tb seagate exos hdds and it takes 30 hours to clone with the dd command in linux
scanning like would take time, but not as long as you would think
as long as cpu can keep up, and its reads are seq, it would be done in well under a day
Its actually way more expensive, 20TB drives are the best value rn and have been for a while, and 16 before that, half the $/TB compared to small drives
Thats why you just reuse old cases if you're not into paying $300 for a fractal or whatever.
Modern cases are a scam, just use a laptop at that point if you're going to throw away all your expansions for "looks" (functionality looks better tho)
Takes a few days, its fine, 30hrs for 4TB is definitely not normal, but I guess it could be because you have a ton of tiny files, use some crap software or an SMR HDD if it takes that long.
This can also mean that the dd will be significantly faster than an rsync depending upon the data makeup of the disk; for example if the filesystem has tons of very small files rsync may be substantially slower due to the disk needing to seek substantially more where as a dd is copying blocks so it is pretty much all sequential reads and writes.
Another tip to speed up your cloning via dd is to specify a larger block size within the limits of your memory (RAM). The `bs=` argument tells the dd command how much data to read in to the buffer before flushing it to the destination. So if you have something like 16GB of RAM then you can specify `bs=8G` so it will read in 8GB of data at a time and then flush that and write 8GB to the destination disk. This will significantly increase the speed of the dd because you aren't having it flush the buffer every 512 bytes. This can/will cause a buffer overrun at the end of the disk where the last block of 8GB will overrun the end of the disk (unless it happens to perfectly align to the disk size), however, the "data" that is past the end of the disk would be all 0s so it shouldn't matter and all you'll need to do is run an fsck on the filesystem that is in the last partition on the disk to fix any broken end-of-disk flag.
It is normal if they are just doing `dd if=/dev/sda of=/dev/sdb` without specifying any other directives. By default dd will us the default block size of 512bytes so it will read in 512bytes to the buffer, flush that 512bytes to write it out to the destination disk and then proceed to the next 512bytes. This adds a ton of overhead in both buffer commands at the kernel level and disk commands being sent to both disks controllers.
Specifying a larger block size within the bounds of your available system memory will substantially increase the speed of running a block-level dd clone.
True, if all you are trying to do is a file-level backup and not an actual clone/replica then rsync is likely a better solution in most cases.
E.g. if you have said disk partitioned with a single full-disk partition and one filesystem, mounted to something like /steamlibrary and all you want to do is backup all of those files periodically then rsync is probably the better option. If you are trying to make a replica of your entire OS on a bootable disk with multiple partitions and filesystems; dd will likely be a better option unless you are comfortable rebuilding and fixing the things that will not be captured via an rsync in that scenario. (grub/bootloader, fstab, /etc/default/ configurations, etc.)
Another thing to note on this topic is that dd is going to be an actual block-level replica, which includes the disks/partitions GUIDs and the filesystem(s) UUID(s). As such you can't leave both the source and destination disks attached to the system at the same time during boot because both disks will have the exact same identifiers; and the same with triggering the system to parse fstab and/or mount by ID as the filesystems on both disks will be the same exact filesystems including their identifiers/metadata.
i was going to use rescuezilla instead for its clone function but had technical problems, not sure if that would have also been faster than dd ¯\_(ツ)_/¯