Re: Build servers offline due to failed SSD
> On 9 Mar 2021, at 5:53 am, Dave C via macports-users > wrote: > > Old technology drives use magnetism to hold bits. This works for decades, or > so I’ve read. Usually the motor or bearings die before the magnetic medium > fails. > > Solid State Drives use memory chips to hold bits. These “bit holders” can > wear out after a few trillion transitions (changing from 1 to 0 and 0 to 1). > I’d you’re using it in your laptop or PC, you’ll likely have no problems for > many years. In an internet-connected server, you may exceed those maximum > write cycles sooner rather than later. > Dave I was just reading up, interesting info … SSDs work (as do eproms) by having an isolated ‘chamber’. You get electrons in or out of the chamber using quantum tunneling [it disapears here and teleports there] based on probability, higher with an electric field Repeated used breaks down the insulation of the isolated ‘chamber’ SLC (the lowest capacity and most expensive) store 0 or 1 (volts or whatever unit) and are most tolerant of damage 0 is 0, 1, 2, 3 units, 1 = 6, 7 8 units with 4 more likely a 0 and 5 more likely a 1 (say) DLC store 0, 1 2 ,3 units and are less tolerant of an extra, or a fewer u TCL DLC store 0, 1, 2, 3 … 13, 14, 15 units. Are the cheapest but most fragile ie 13 can leak away to 12, or gain from 13 to 14 But the link earlier is discuusion showed drives rated at 300 TBW going well past that to 1 or 2 PBW (Peta is 1000 times Tera) In use a HD (specially with lots of them) is more likely to fail than SSD. Seagates old paper ‘ATA more than an interface’ says this: Drive 1 seeks and the bump knocks others off track. They seek back knocking others off track. Process continues until a disk fails. Their 10 year old assesment of reasons is even more relevant on todays drives. SSDs generally give more warning that ’the end is nigh’ All considered I’d take SSD for work disks and HD for long term backup Heck in my day (ouch) we’d teach 'tower of hanoi' backup stratedgy using tape. why not do likewise with HDs. Timemachine certainly make that easy. James > Dave > > - - - > >>> On Sun, 7 Mar 2021, Michael A. Leonetti via macports-users wrote: >>> >>> I’d really love to know more about what you’re saying here. Up until I just >>> read what you wrote, I thought SSDs were the savior of HDDs. >> >> Real disk drives [tm] have their N/S magnetic poles lined up pretty much >> forever; SSDs rely upon capacitors storing their charge forever (hah!). >> >> You need to have an electronics background to understand... >> >> -- Dave (VK2KFU) >
Re: migration hickup
> On 9 Mar 2021, at 4:12 am, joerg van den hoff wrote: > > > > On 08.03.21 21:01, Rainer Müller wrote: >> On 08/03/2021 17.44, joerg van den hoff wrote: >>> Now, after the data transfer completed, on the new machine I do have a >>> (seemingly/so far) working Macports installation: Migration Assistant >>> actually >>> transferred the stuff in /opt, too. >>> >>> BUT, when now trying to selfupdate on the new machine, I get the >>> message/warning: >>> >>> Warning: Failed to copy com.apple.dt.Xcode.plist to >>> /opt/local/var/macports/home/Library/Preferences: could not set owner for >>> file >>> "/opt/local/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist": >>> user "macports" does not exist >>> >>> although `finger macports' reports for the new machine that the user is >>> known >>> >>> Login: macports Name: MacPorts >>> Directory: /opt/local/var/macports/homeShell: /usr/bin/false >>> Never logged in. >>> No Mail. >>> No Plan. >>> >>> as does `id macports'. >>> >>> what am I missing? > > thanks for your reply. > >> I am not sure, but it might be that the message shown above is a bit >> inaccurate >> and it is the "macports" group that is missing? > > the message says it can't set the *owner* so it seems to actually mean _user_ > does not exist, no? > >> Please check that the user and group do exist for dscl (Directory Services): >> dscl . -read /Users/macports >> dscl . -read /Groups/macports > > yes, they do (no error messages, some reporting of properties). so I really > don't see what is missing or has been broken by an seemingly incomplete > transfer of information from the old machine basically, I don't > understand how the machine can complain about "non-existent user macports" > despite this seemingly not being true. > >> In any case, running the MacPorts install either from the .dmg or from source >> once again should recreate both the user and group named "macports". > > just to be sure: re-installing will not confuse/corrupt the database > regarding what is already installed via macports? I would prefer to keep > /opt/local intact and usable... Jorge you are brave, perhaps foolhardy. The wiki tells you exactly what to do. Basically * get a list of ports from the old machine * install macports on new * restore your ports I have found this to be far less time consuming than troubleshooting. That said a timemachine backup (on the same os version) works perfectly. James
Re: Build servers offline due to failed SSD
I think most people who talk about servers and HDs/SSDs are referring to commercial internet-connected servers. Yes, a private server will likely see a lesser degree of service/use and storage drives can be uprated (the opposite of derated) for greater lifetime. Dave > I’ve been looking at VPS providers, and most of them offer SSD-based VPSs, > so they seem to be increasingly popular. I suspect that most VPSs do not get > consistently hammered, though. > > Peter
Re: Build servers offline due to failed SSD
Old technology drives use magnetism to hold bits. This works for decades, or so I’ve read. Usually the motor or bearings die before the magnetic medium fails. Solid State Drives use memory chips to hold bits. These “bit holders” can wear out after a few trillion transitions (changing from 1 to 0 and 0 to 1). I’d you’re using it in your laptop or PC, you’ll likely have no problems for many years. In an internet-connected server, you may exceed those maximum write cycles sooner rather than later. Dave - - - >> On Sun, 7 Mar 2021, Michael A. Leonetti via macports-users wrote: >> >> I’d really love to know more about what you’re saying here. Up until I just >> read what you wrote, I thought SSDs were the savior of HDDs. > > Real disk drives [tm] have their N/S magnetic poles lined up pretty much > forever; SSDs rely upon capacitors storing their charge forever (hah!). > > You need to have an electronics background to understand... > > -- Dave (VK2KFU)
Re: Build servers offline due to failed SSD
On Sun, 7 Mar 2021, Todd Doucet wrote: HDs fail also, obviously, but tend not to be so predictable about it. That of course depends upon the HD and the OS; my (FreeBSD) server's drive is around 20 years old, and is still going strong. There's also software that monitors the health of the disk. -- Dave
Re: Build servers offline due to failed SSD
On Sun, 7 Mar 2021, Michael A. Leonetti via macports-users wrote: I’d really love to know more about what you’re saying here. Up until I just read what you wrote, I thought SSDs were the savior of HDDs. Real disk drives [tm] have their N/S magnetic poles lined up pretty much forever; SSDs rely upon capacitors storing their charge forever (hah!). You need to have an electronics background to understand... -- Dave (VK2KFU)
where is development version?
I need to install the MacPorts development version 2.6.99 (from source). Where is it? --- Murray Eisenbergmurrayeisenb...@gmail.com 503 King Farm Blvd #101 Rockville, MD 20850-6667Mobile (413)-427-5334
Re: migration hickup
On 08.03.21 21:01, Rainer Müller wrote: On 08/03/2021 17.44, joerg van den hoff wrote: Now, after the data transfer completed, on the new machine I do have a (seemingly/so far) working Macports installation: Migration Assistant actually transferred the stuff in /opt, too. BUT, when now trying to selfupdate on the new machine, I get the message/warning: Warning: Failed to copy com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences: could not set owner for file "/opt/local/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist": user "macports" does not exist although `finger macports' reports for the new machine that the user is known Login: macports Name: MacPorts Directory: /opt/local/var/macports/home Shell: /usr/bin/false Never logged in. No Mail. No Plan. as does `id macports'. what am I missing? thanks for your reply. I am not sure, but it might be that the message shown above is a bit inaccurate and it is the "macports" group that is missing? the message says it can't set the *owner* so it seems to actually mean _user_ does not exist, no? Please check that the user and group do exist for dscl (Directory Services): dscl . -read /Users/macports dscl . -read /Groups/macports yes, they do (no error messages, some reporting of properties). so I really don't see what is missing or has been broken by an seemingly incomplete transfer of information from the old machine basically, I don't understand how the machine can complain about "non-existent user macports" despite this seemingly not being true. In any case, running the MacPorts install either from the .dmg or from source once again should recreate both the user and group named "macports". just to be sure: re-installing will not confuse/corrupt the database regarding what is already installed via macports? I would prefer to keep /opt/local intact and usable... best, joerg Rainer
Re: migration hickup
On 08/03/2021 17.44, joerg van den hoff wrote: > Now, after the data transfer completed, on the new machine I do have a > (seemingly/so far) working Macports installation: Migration Assistant actually > transferred the stuff in /opt, too. > > BUT, when now trying to selfupdate on the new machine, I get the > message/warning: > > Warning: Failed to copy com.apple.dt.Xcode.plist to > /opt/local/var/macports/home/Library/Preferences: could not set owner for file > "/opt/local/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist": > user "macports" does not exist > > although `finger macports' reports for the new machine that the user is known > > Login: macports Name: MacPorts > Directory: /opt/local/var/macports/home Shell: /usr/bin/false > Never logged in. > No Mail. > No Plan. > > as does `id macports'. > > what am I missing? I am not sure, but it might be that the message shown above is a bit inaccurate and it is the "macports" group that is missing? Please check that the user and group do exist for dscl (Directory Services): dscl . -read /Users/macports dscl . -read /Groups/macports In any case, running the MacPorts install either from the .dmg or from source once again should recreate both the user and group named "macports". Rainer
migration hickup
hi there, today I have set up a new macbook, using the "Migration Assistant" app to move my stuff from the old machine to the new one. the only thing which I *excluded* from the offered list of user accounts and other data (Applications etc.) was the `macports' user since "Migration Assistant" indicated that it would move the macports user's home dir to /Users on the new machine -- which I assumed to be not desirable since on the old machine I see Login: macports Name: MacPorts Directory: /opt/local/var/macports/home Shell: /usr/bin/false Never logged in. No Mail. No Plan. and I presume it should stay in that location... Now, after the data transfer completed, on the new machine I do have a (seemingly/so far) working Macports installation: Migration Assistant actually transferred the stuff in /opt, too. BUT, when now trying to selfupdate on the new machine, I get the message/warning: Warning: Failed to copy com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences: could not set owner for file "/opt/local/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist": user "macports" does not exist although `finger macports' reports for the new machine that the user is known Login: macports Name: MacPorts Directory: /opt/local/var/macports/home Shell: /usr/bin/false Never logged in. No Mail. No Plan. as does `id macports'. what am I missing? thanks, joerg
Re: Build servers offline due to failed SSD
> On 7 Mar 2021, at 3:26 pm, Dave C via macports-users > wrote: > > This applies to affordable SSDs. As you say, the ones that are on par (re. > reliability) with HDDs are $pendy. > > It’s something to do with an SSD’s limited number of write cycles, if I > remember... > > Dave > > - - - > >> Isn’t SSD a bad choice for server duty? No server farms use them, apparently >> due to short lifespan. The reality needs to be carefully weighed up SSDs are rated in TBW. That is Terrabytes Written The Cheaper SSDs may be 300 or 600 TBW the more expensive may be 1200 TBW or even 2500 TBW. The TBW rating depends on size, I’ve put a 2T SSD (600 TBW) in my iMac and after a year i see life expected of 65 years. So no SSD for a build farm is not a bad idea. The performance benefits far outweigh the 50+ year hastle of replacing. The MTBF of spinning rust is 10 odd years, ssd is many times that. But remembering my uni stats the chance of a light globe, with a life of 1000 hours failing, when you have a few dozen bulbs (in my test question) was 20 min !!! Enterprize Disks have a longer life, but as I said it is complicated. James
Re: Build servers offline due to failed SSD
Here‘s an in depth discussion on SSD reliability, a little more detailed than „(not) recommended“ from someone with a lot of first hand experience, it seems: https://www.backblaze.com/blog/how-reliable-are-ssds/
