Re: [atlas] USB drive more harmful than helpful?
It doesn't help, when we're talking about Atlas probes. I have one probe, where external flash died twice, even it's placed in datacenter with UPS-protected power. On 23.05.16 15:35, "ripe-atlas on behalf of James R Cutler" wrote: Stable power, as from a UPS, also isolates the probe from power glitches which may cause rebooting of the probe, thus adding to the write count. Not to mention corruption from power failure during writes. Opinion: If the device/system/operation is at all important, use of a UPS is effectively mandatory.
Re: [atlas] USB drive more harmful than helpful?
> On May 23, 2016, at 8:41 AM, Wilfried Woeber wrote: > > [...] >> Has anyone tested how many writes are going on to the ATLAS thumb >> drive? Perhaps with all the failures within a year of start, perhaps >> too many writes are taking place? > > I know that a very small number of probes is not a valid basis for statistics, > but there wasn't a USB drive failure yet for the long-term, always-on probe. > > But they are powered with dedicated, stable power sources. > Thus I tend to lean more towards the explanation involving level or stability > of power, rather than # of writes. > > FWIW, > Wilfried > >> Regards, >> Hank > Stable power, as from a UPS, also isolates the probe from power glitches which may cause rebooting of the probe, thus adding to the write count. Not to mention corruption from power failure during writes. Opinion: If the device/system/operation is at all important, use of a UPS is effectively mandatory. James R. Cutler james.cut...@consultant.com PGP keys at http://pgp.mit.edu signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [atlas] USB drive more harmful than helpful?
Le 23/05/2016 à 14:41, Wilfried Woeber a écrit : > [...] >> Has anyone tested how many writes are going on to the ATLAS thumb >> drive? Perhaps with all the failures within a year of start, perhaps >> too many writes are taking place? > I know that a very small number of probes is not a valid basis for statistics, > but there wasn't a USB drive failure yet for the long-term, always-on probe. > > But they are powered with dedicated, stable power sources. > Thus I tend to lean more towards the explanation involving level or stability > of power, rather than # of writes. > > FWIW, > Wilfried > >> Regards, >> Hank FWIW, my failed #12033 probe was powered using only 1 usb port from my ISP provided router. I’ve plugged the replacement one on a 2+1 A dedicated power supply. So while that second one hasn’t been around long enough to be relevant, the first one fall in the low power level issue range. Bruno signature.asc Description: OpenPGP digital signature
Re: [atlas] USB drive more harmful than helpful?
[...] > Has anyone tested how many writes are going on to the ATLAS thumb > drive? Perhaps with all the failures within a year of start, perhaps > too many writes are taking place? I know that a very small number of probes is not a valid basis for statistics, but there wasn't a USB drive failure yet for the long-term, always-on probe. But they are powered with dedicated, stable power sources. Thus I tend to lean more towards the explanation involving level or stability of power, rather than # of writes. FWIW, Wilfried > Regards, > Hank
Re: [atlas] USB drive more harmful than helpful?
Fwiw, I always power directly from an outlet, never tributary on the USB. I've yet to have such fails, so my anecdata aligns with the underpower theory. On May 20, 2016 15:08, "Phillip Remaker" wrote: So I have a few theories. I have now had 3 different USB sticks fail on me: Two Sandisk 4GB SDCZ33 and one cheap generic 8GB replacement. The power draw of the TP-Link system + USB is probably more than the opportunistic USB ports they get plugged in to. An underpowered probe runs great MOST of the time, but a flash bit write is probably the highest power strain and Flash can get really unhappy with power interrupts, based on this SSD research: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf I usually use a 500mA or 800mA supply, or tap a nearby router USB port in that range. I suspect the system may demand 1200mA or more. When most flash sticks get errored out enough, they permanently fail into a read only mode, or become fully unreadable. Read-only mode can be reset on some models, but it is not recommended by the vendor. At least one of the failed SANdisk units I had was stuck in a read-only mode. Also, probes may be subjected to ungraceful power down situations, depending on where they are stationed. That can also be a flash drive killer. I don't think we are hitting the write limits of the sticks. I suspect the units are often in underpowered or ungraceful pwoer-down situations, or the USB flash itself is not responding gracefully to poweroff situations. I don't suppose RIPE buys enough USB sticks to get to talk to engineers at SanDISK? I know the newer Raspberry Pi will report when it is in an underpowered situation. Can the TP-Link detect and warn when underpowered? What is the minimum power recommended for TP-Link + USB? Also, are there any USB sticks that have lower power needs and are more robust in low power IoT situations? Is anyone trying to post-mortem the failed sticks? On Fri, May 20, 2016 at 10:03 AM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > > We have no clear idea why they fail. It seems that time to failure is > > highly variable. > > Can you correlate tests-until-failure or data-written-until-failure? > > One of mine has failed at least two times now, and it could be that > people just *love* to run tests from 3320... > > My gen 1 probe in 5539 has never had *any* issues. > > gert > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >
Re: [atlas] USB drive more harmful than helpful?
On 2016/05/21 21:32 , Hank Nussbacher wrote: > On 20/05/2016 22:08, Phillip Remaker wrote: >> I don't suppose RIPE buys enough USB sticks to get to talk to >> engineers at SanDISK? >> > Sandisk R&D is located in Israel: > http://www.globes.co.il/en/article-sandisk-acquisition-affects-650-israeli-employees-1001075338 > I could probably arrange a meeting with the technical staff there > provided there is a clear document detailing the issue. > Maybe RIPE ATLAS technical staff would like to come to a meeting? We switched from SanDisk to Verbatim because the failure rate of the SanDisk was too high. Unfortunately, the log files that contain details about the USB sticks are archived in a way that makes them hard to access. But we will try to analyze those logs soon to see what we can get out of them. Independent of that, it would be nice if we could figure out a way to induce failures (instead of having to way for probes in the field to end up with a corrupt filesystem) and to figure out what causes those failures. One thing we currently wonder is if a marginal power supply (as seen from the USB stick) would cause corruption or not. Philip
Re: [atlas] USB drive more harmful than helpful?
It was powered through the dedicated wall plug included with the probe. On May 22, 2016 12:03:39 AM GMT+02:00, Phillip Remaker wrote: >How was the drive powered? Dedicated supply, or a port on a router? > >On Sat, May 21, 2016 at 1:32 PM, Michael Ionescu >wrote: > >> On May 20, 2016 9:08:08 PM GMT+02:00, Phillip Remaker > >> wrote: >> >I don't suppose RIPE buys enough USB sticks to get to talk to >engineers >> >at SanDISK? >> >> I just had a Verbatim drive originally supplied with the probe go >> read-only, so I would say RIPE is not procuring only SanDISK.
Re: [atlas] USB drive more harmful than helpful?
On May 20, 2016 3:58:06 PM GMT+02:00, Philip Homburg wrote: >No, the probe actually runs from the USB stick. The internal 4MB flash >is just enough to initialize the USB stick in a secure way. And even >that is already tricky. Could you perhaps write some statistical data regarding drive usage to a cleartext partition that could be evaluated by the hoster once the probe is in limbo? --
Re: [atlas] USB drive more harmful than helpful?
On May 20, 2016 9:08:08 PM GMT+02:00, Phillip Remaker wrote: >I don't suppose RIPE buys enough USB sticks to get to talk to engineers >at SanDISK? I just had a Verbatim drive originally supplied with the probe go read-only, so I would say RIPE is not procuring only SanDISK. --
Re: [atlas] USB drive more harmful than helpful?
On 20/05/2016 22:08, Phillip Remaker wrote: > > When most flash sticks get errored out enough, they permanently fail > into a read only mode, or become fully unreadable. Read-only mode can > be reset on some models, but it is not recommended by the vendor. At > least one of the failed SANdisk units I had was stuck in a read-only mode. > > Also, probes may be subjected to ungraceful power down situations, > depending on where they are stationed. That can also be a flash drive > killer. > > I don't think we are hitting the write limits of the sticks. I suspect > the units are often in underpowered or ungraceful pwoer-down > situations, or the USB flash itself is not responding gracefully to > poweroff situations. > > I don't suppose RIPE buys enough USB sticks to get to talk to > engineers at SanDISK? > Sandisk R&D is located in Israel: http://www.globes.co.il/en/article-sandisk-acquisition-affects-650-israeli-employees-1001075338 I could probably arrange a meeting with the technical staff there provided there is a clear document detailing the issue. Maybe RIPE ATLAS technical staff would like to come to a meeting? Regards, Hank
Re: [atlas] USB drive issues
as a probe 1 user we dont see these problems as not memory card based but i do use usb power from homehub. if there is a spare probe3 is avail i am happy to test usb power use colin Sent from my iPhone > On 21 May 2016, at 10:14, Geert Jan de Groot > wrote: > > At the first hint of trouble, it may actually have been premature, > I swapped the USB drive on my probe with a brandname replacement. > Note that there is a lot of poor quality stuff, especially in > "giveaway" drives, and the fact that the disc is encrypted > of course does not help heuristics in the USB drive controller > to lengthen the drive life. > > The replacement was painless: power down, insert blank disk, > powerup, did the dishes, when I was done the probe was done > initializing and everything was working fine. > > I've added "replaced-broken-sandisk-usb-stick" to the probe. > Perhaps this is a useful heuristic to monitor how prevalent > the problem really is. > > Geert Jan >
Re: [atlas] USB drive issues
At the first hint of trouble, it may actually have been premature, I swapped the USB drive on my probe with a brandname replacement. Note that there is a lot of poor quality stuff, especially in "giveaway" drives, and the fact that the disc is encrypted of course does not help heuristics in the USB drive controller to lengthen the drive life. The replacement was painless: power down, insert blank disk, powerup, did the dishes, when I was done the probe was done initializing and everything was working fine. I've added "replaced-broken-sandisk-usb-stick" to the probe. Perhaps this is a useful heuristic to monitor how prevalent the problem really is. Geert Jan
Re: [atlas] USB drive more harmful than helpful?
So I have a few theories. I have now had 3 different USB sticks fail on me: Two Sandisk 4GB SDCZ33 and one cheap generic 8GB replacement. The power draw of the TP-Link system + USB is probably more than the opportunistic USB ports they get plugged in to. An underpowered probe runs great MOST of the time, but a flash bit write is probably the highest power strain and Flash can get really unhappy with power interrupts, based on this SSD research: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf I usually use a 500mA or 800mA supply, or tap a nearby router USB port in that range. I suspect the system may demand 1200mA or more. When most flash sticks get errored out enough, they permanently fail into a read only mode, or become fully unreadable. Read-only mode can be reset on some models, but it is not recommended by the vendor. At least one of the failed SANdisk units I had was stuck in a read-only mode. Also, probes may be subjected to ungraceful power down situations, depending on where they are stationed. That can also be a flash drive killer. I don't think we are hitting the write limits of the sticks. I suspect the units are often in underpowered or ungraceful pwoer-down situations, or the USB flash itself is not responding gracefully to poweroff situations. I don't suppose RIPE buys enough USB sticks to get to talk to engineers at SanDISK? I know the newer Raspberry Pi will report when it is in an underpowered situation. Can the TP-Link detect and warn when underpowered? What is the minimum power recommended for TP-Link + USB? Also, are there any USB sticks that have lower power needs and are more robust in low power IoT situations? Is anyone trying to post-mortem the failed sticks? On Fri, May 20, 2016 at 10:03 AM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > > We have no clear idea why they fail. It seems that time to failure is > > highly variable. > > Can you correlate tests-until-failure or data-written-until-failure? > > One of mine has failed at least two times now, and it could be that > people just *love* to run tests from 3320... > > My gen 1 probe in 5539 has never had *any* issues. > > gert > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >
Re: [atlas] USB drive more harmful than helpful?
Hi, On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > We have no clear idea why they fail. It seems that time to failure is > highly variable. Can you correlate tests-until-failure or data-written-until-failure? One of mine has failed at least two times now, and it could be that people just *love* to run tests from 3320... My gen 1 probe in 5539 has never had *any* issues. gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [atlas] USB drive more harmful than helpful?
On 2016/05/20 14:57 , Hank Nussbacher wrote: > Has anyone tested how many writes are going on to the ATLAS thumb > drive? Perhaps with all the failures within a year of start, perhaps > too many writes are taking place? We have no clear idea why they fail. It seems that time to failure is highly variable.
Re: [atlas] USB drive more harmful than helpful?
On 2016/05/20 14:37 , Michael Ionescu wrote: > If the main reason for the drive is to cache data during unavailability > of the command and control center, this may not be worth the effort. No, the probe actually runs from the USB stick. The internal 4MB flash is just enough to initialize the USB stick in a secure way. And even that is already tricky.
Re: [atlas] USB drive more harmful than helpful?
+1. I lost most of the probes this way and I'm not really sure how to recover them - I need to ask for a batch of USB drives or ask all the hosts to remove them... can't this be handled better with a firmware replacement? I would at least then ask all the hosts to unplug the USB and leave the hosts as is. Gil On Fri, May 20, 2016 at 4:06 PM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 02:37:44PM +0200, Michael Ionescu wrote: > > >From both my own (short term) experience and from what's being written > on this list, I'm getting the impression that the USB drive may be costing > more than it's worth. > [..] > > Any thoughts? > > The USB outages and the lack of proper guidance for probe hosts about > the problem status and how to get the probes back has been my gripe #1 > for a while now. > > So, yes, this needs fixing, one way or the other. > > gert > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >
Re: [atlas] USB drive more harmful than helpful?
Hi, On Fri, May 20, 2016 at 02:37:44PM +0200, Michael Ionescu wrote: > >From both my own (short term) experience and from what's being written on > >this list, I'm getting the impression that the USB drive may be costing more > >than it's worth. [..] > Any thoughts? The USB outages and the lack of proper guidance for probe hosts about the problem status and how to get the probes back has been my gripe #1 for a while now. So, yes, this needs fixing, one way or the other. gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [atlas] USB drive more harmful than helpful?
On 20/05/2016 15:37, Michael Ionescu wrote: Interesting idea to make the USB drive optional. Based on literature: https://en.wikipedia.org/wiki/USB_flash_drive#Failures https://askleo.com/can_a_usb_thumbdrive_wear_out/ - 10,000-100,000 http://cfgearblog.blogspot.co.il/2011/03/how-long-does-flash-drive-last_22.html - 10,000-1M Has anyone tested how many writes are going on to the ATLAS thumb drive? Perhaps with all the failures within a year of start, perhaps too many writes are taking place? Regards, Hank > >From both my own (short term) experience and from what's being > written on this list, I'm getting the impression that the USB drive > may be costing more than it's worth. > > I have in only about 3 months experienced multiple probe issues due to > USB drives and there have been multiple threads on this list which > suggest that I am far from alone. > > I will go so far as to suspect that a substantial number of > disconnected and abandoned probes have similar issues, but the hosters > may be unwilling or unable to spend the necessary time to investigate > and resolve them. > > If the main reason for the drive is to cache data during > unavailability of the command and control center, this may not be > worth the effort. > > I would suggest making the drive optional. That may mean fewer data > points from and/or fewer UDMs possible on those probes without a > functioning drive. But it may also mean a couple thousand probes more > connected and therefore available for measurements at all. > > I'm not saying that probes should not ask for their drives to be > fixed/replaced, but it should not be a requirement for the probe to > run. One might give an incentive to hosters to run their probes with > functioning drives by giving less credits for connected probes without > a drive. > > Any thoughts? > > Michael > -- > Sent from a mobile. Please excuse my brevity. // M: +49-163-6866568
[atlas] USB drive more harmful than helpful?
>From both my own (short term) experience and from what's being written on this >list, I'm getting the impression that the USB drive may be costing more than >it's worth. I have in only about 3 months experienced multiple probe issues due to USB drives and there have been multiple threads on this list which suggest that I am far from alone. I will go so far as to suspect that a substantial number of disconnected and abandoned probes have similar issues, but the hosters may be unwilling or unable to spend the necessary time to investigate and resolve them. If the main reason for the drive is to cache data during unavailability of the command and control center, this may not be worth the effort. I would suggest making the drive optional. That may mean fewer data points from and/or fewer UDMs possible on those probes without a functioning drive. But it may also mean a couple thousand probes more connected and therefore available for measurements at all. I'm not saying that probes should not ask for their drives to be fixed/replaced, but it should not be a requirement for the probe to run. One might give an incentive to hosters to run their probes with functioning drives by giving less credits for connected probes without a drive. Any thoughts? Michael -- Sent from a mobile. Please excuse my brevity. // M: +49-163-6866568
Re: [atlas] USB drive
Hi, I need to follow up on this once more... The same probe, which had now been working again for several weeks after it reformatted its drive, I have now found the drive to be read-only. After replacing the drive with a new one, the probe is once again fine. While troubleshooting I have found that the probe does not connect as long as there is no functioning drive present. This makes troubleshooting unnecessarily difficult. I would suggest adding a couple of (SOS?) messages that would run regardless of the presence of a drive, such as: - detected no USB drive on bootup - detected insertion of USB drive - detected removal of USB drive - detected read-only USB drive - Starting fsck on USB drive - Ended fsck on USB drive (possibly indicating success/failure) - Starting to reformat USB drive - Ended reformatting USB drive (possibly indicating success/failure) and possibliy something that would point towards a corrupt FS - if that is easily detectable, for instance by checking the integrity of a known file within the FS. Just my 2ct. Michael On 30.03.2016 13:50, Philip Homburg wrote: > Hi Michael, > [...] > In general, the probe doesn't care what is on the USB stick. So wiping > or formatting the stick is not needed. > > There is at the moment one rare exception. The filesystem can go corrupt > to the point the fsck hangs. > [...] > Philip
Re: [atlas] USB drive
Hi Philip, thanks for clearing this up. It would be really great to take some of the guesswork out of these cases, by adding one or two checks regarding the thumbdrive and file system status, transmitting negative results via descriptive SOS messages and/or system status tags. On my probe the USB problems led to a system tag "Firewall problem suspected". This is quite misleading. After your description I would suspect the FS issue impeded the probe so deeply that it wasn't able to call home at all anymore. To my understanding, probes should be fire-and-forget as much as possible, so I think any fsck should be run in a way that would not impede an otherwise functioning probe. Michael On 30.03.2016 13:50, Philip Homburg wrote: > Hi Michael, > [...] > In general, the probe doesn't care what is on the USB stick. So wiping > or formatting the stick is not needed. > > There is at the moment one rare exception. The filesystem can go corrupt > to the point the fsck hangs. > [...] > Philip
Re: [atlas] USB drive
Hi, On Wed, Mar 30, 2016 at 01:50:33PM +0200, Philip Homburg wrote: > Currently the probes use an ext2 filesystem, because it is simple and > seemed to work well enough. It worked well in artificially power cycling > the probe for period of time. Of course, reality is worse. This might actually be the reason for the flash issues - from what I could gather, these USB stick controllers understand FAT well enough to do wear-leveling for it, but are not as smart as SSDs who handle "arbitrary block access patterns" properly - so, using "non-FAT" filesystems will make the USB stick (and SD-Cards, for that matter) wear out much faster. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [atlas] USB drive
Hi Michael, > but on further inspections do not contain a valid magic number in their > superblocks, so they are effectively unformatted. I would therefore suspect > that they are not being used by the probe. > > Now the question: > What is the correct layout supposed to look like (primary/secondary, size, > ID, FS-type)? I would like to get my probe back up and running. In general, the probe doesn't care what is on the USB stick. So wiping or formatting the stick is not needed. There is at the moment one rare exception. The filesystem can go corrupt to the point the fsck hangs. In that case, wiping the entire USB stick will help. To get the probe to reinitialise the USB stick, the correct procedure is to power on the probe without USB stick and then insert the USB stick after a few minutes (10 to be safe). The procedure suggested by Gert Doering will also work. But should not be necessary. The filesystems on the UDB stick are encrypted, that why you can't find any valid magic numbers. > Bonus question: > What can I expect to find in point of files/data on the drive, that would > tell me whether the probe was working correctly until I cut power and removed > the drive? You cannot find anything on the drive. Only the probe has the encryption keys. Currently the probes use an ext2 filesystem, because it is simple and seemed to work well enough. It worked well in artificially power cycling the probe for period of time. Of course, reality is worse. At some point I'll try to experiment with adding journaling to see if it makes a difference. Philip
Re: [atlas] USB drive
Thanks Gert, that helped! The probe was back up after only a couple of minutes. Until the FAQ has been amended, the following might help others: To reset the USB Thumbdrive: Under Windows: https://tails.boum.org/doc/first_steps/reset/windows/index.en.html (stop after the "clean" step) Under Linux: dd if=/dev/zero of=/dev/ bs=512 count=1 Plug the thumbdrive back into the Probe AFTER the Probe has rebooted. SOS History (on the probe's RIPE Atlas Webpage - Network tab) should show Entries with "NO USB" after reboot and then regular entries with no errors, once the thumbdrive has been replaced. Michael signature.asc Description: OpenPGP digital signature
Re: [atlas] USB drive
Hi, On Wed, Mar 30, 2016 at 11:14:11AM +0200, Michael Ionescu wrote: > Now the question: > What is the correct layout supposed to look like (primary/secondary, size, > ID, FS-type)? I would like to get my probe back up and running. dd if=/dev/zero of=/dev/ bs=1m count=1 just zero-out the partition sector and the probe will re-initialize everything (boot up without flash stick, re-insert emptied flash stick, wait an hour or so). This REALLY needs to go into the FAQ that is sent with every "hey, your probe is down!" mail. Plus, "we can hear its SOS requests, and it needs a flash replacement". RIPE NCC folks, are you listening? This is a major annoyance. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpTDYRACceV4.pgp Description: PGP signature
[atlas] USB drive
Hi all, I have a probe that's been down for several days now. I did contact RIPE about it, but support has been superficial. I also didn't yet find the level of technical detail I need in the information on the website and in this list's archives. The 8GB drive, when reformatted on a windows box with FAT32 as per support instructions, surprisingly only comes out with a 1GB partition. Inspecting the drive under linux, I find multiple partitions, with only the first containing an a fat32 filesystem: Platte /dev/sdc: 7927 MByte, 7927234560 Byte 244 Köpfe, 62 Sektoren/Spur, 1023 Zylinder, zusammen 15482880 Sektoren Einheiten = Sektoren von 1 × 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Festplattenidentifikation: 0xc3072e18 Gerät boot. AnfangEnde Blöcke Id System /dev/sdc12048 2099199 1048576b W95 FAT32 /dev/sdc2 2099200 4196351 1048576 83 Linux /dev/sdc3 4196352 6293503 1048576 83 Linux On first glance, the others contain ext2 filesystems # fsck -N /dev/sdc? fsck von util-linux 2.20.1 [/sbin/fsck.vfat (1) -- /dev/sdc1] fsck.vfat /dev/sdc1 [/sbin/fsck.ext2 (2) -- /dev/sdc2] fsck.ext2 /dev/sdc2 [/sbin/fsck.ext2 (3) -- /dev/sdc3] fsck.ext2 /dev/sdc3 but on further inspections do not contain a valid magic number in their superblocks, so they are effectively unformatted. I would therefore suspect that they are not being used by the probe. Now the question: What is the correct layout supposed to look like (primary/secondary, size, ID, FS-type)? I would like to get my probe back up and running. Bonus question: What can I expect to find in point of files/data on the drive, that would tell me whether the probe was working correctly until I cut power and removed the drive? Thanks, Michael
