search for: irretrievable

On Sun, May 14, 2017 at 10:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/14/2017 11:06 AM, Daniel Berlin wrote: > > > > On Sun, May 14, 2017 at 8:37 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 03/01/2017 05:30 PM, Daniel Berlin via llvm-dev wrote: >> >> So, https://bugs.llvm.org/show_bug.cgi?id=32056 is an example

John R Pierce wrote: > On 5/31/2017 8:04 AM, m.roth at 5-cent.us wrote: >> I've got an old RAID that I attached to a box. LSI card, and the RAID >> has 12 drives, for a total RAID size of 9.1TB, I think. I started shred >> /dev/sda the Friday before last... and it's still running. Is this >> reasonable for it to be taking this long...? > > not at all

Hi list, I am experimenting with ocfs2 (rpm package: 1.2.2-0.2), using linux-ha 2.0.8 (all running on a SLES 10 x86-64, rpm packages from linux-ha.org) for the heartbeat. The three nodes are connected on a gigabit switch. From time to time I have problems to unmount a drive, and I have to reboot the whole system to fix the problem. When these lockups occur, I see these messages in

On 13/09/2019 15:34, Marco Gaiarin via samba wrote: > Mandi! Rowland penny via samba > In chel di` si favelave... > >>> https://github.com/fumiyas/smbldap-tools >> Even that points to gna.org: > Ok, but GNA is closed, now, and this has commits (seems imported from > GNA) until 2016... > That is three years ago and all it would take is for Perl to do what

...provide a doc, but i can describe what I believe to be the >> biggest problem. >> >> In a GH PR, comments are associated with commit hashes. If a commit hash >> ceases to exist, so do all comments associated with it. The comments are >> quite literally destroyed and irretrievable. >> > > Either I'm misunderstand something, or this is just blatantly incorrect. > Assuming we're talking about pull request reviews here, review comments do > not get lost, regardless of how you rebase the pull request branch. > Try this experiment: 1. Create a PR 2....

...Information Systems Security (ICISS 2008) > that declares the ?great wiping controversy? about how many passes of > overwriting with various data values to be settled: their research > demonstrates that a single overwrite using an arbitrary data value > will render the original data irretrievable even if MFM and STM > techniques are employed. > > The researchers found that the probability of recovering a single bit > from a previously used HDD was only slightly better than a coin toss, > and that the probability of recovering more bits decreases > exponentially so that...

On Sun, May 14, 2017 at 8:37 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 03/01/2017 05:30 PM, Daniel Berlin via llvm-dev wrote: > > So, https://bugs.llvm.org/show_bug.cgi?id=32056 is an example showing our > current TBAA tree for union generation is definitely irretrievably broken. > I'll be honest here. I'm pretty sure your proposal doesn't go far

On Sun, May 14, 2017 at 11:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/14/2017 12:49 PM, Daniel Berlin wrote: > > > > On Sun, May 14, 2017 at 10:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 05/14/2017 11:06 AM, Daniel Berlin wrote: >> >> >> >> On Sun, May 14, 2017 at 8:37 AM, Hal Finkel <hfinkel at

...Systems Security (ICISS 2008) >> that declares the ?great wiping controversy? about how many passes of >> overwriting with various data values to be settled: their research >> demonstrates that a single overwrite using an arbitrary data value >> will render the original data irretrievable even if MFM and STM >> techniques are employed. >> >> The researchers found that the probability of recovering a single bit >> from a previously used HDD was only slightly better than a coin toss, >> and that the probability of recovering more bits decreases >> e...

...ild is at around 8% Ok, I stop the array and rebuild with mdadm --create /dev/md2 --assume-clean --level=5 --chunk --raid- devices=8 /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/ sdi /dev/sdj Now it says it's going to take another 10 hours to rebuild. How likely are my data irretrievable/gone and at what step would it have happened if so?

Hi, I need some help, As per my requirement, I am trying to lower down the x86_64bit binary LLVM IR to x86 LLVM IR. Instruction of x86_64 binary are as follows, mov rax, 1122334455667788 mov rax, 8877665544332211 To lower down the same in x86, I need to split 'rax' register into 'rax_lower' and 'rax_higher'. Can anybody please give me some pointer to do the same or any

So, https://bugs.llvm.org/show_bug.cgi?id=32056 is an example showing our current TBAA tree for union generation is definitely irretrievably broken. I'll be honest here. I'm pretty sure your proposal doesn't go far enough. But truthfully, I would rather see us come closer to a representation we know works, which is GCC's. Let me try to simplify what you are suggesting, and what we

On 13/09/2019 14:57, Marco Gaiarin via samba wrote: > Mandi! Christopher Sean Hilton via samba > In chel di` si favelave... > >> I've been trying to find news on the smbldap-tools package from IDEALX >> but my google searches have been fruitless. In my FreeBSD port build >> run yesterday I noticed that the port is listed as *broken* because >> the download

On Fri, Sep 13, 2019 at 03:39:44PM +0100, Rowland penny via samba wrote: > On 13/09/2019 15:34, Marco Gaiarin via samba wrote: > > Mandi! Rowland penny via samba > > In chel di` si favelave... > > > > > > https://github.com/fumiyas/smbldap-tools > > > Even that points to gna.org: > > Ok, but GNA is closed, now, and this has commits (seems

Scenario: a) Samba with an ldap backend. b) The ldap database becomes irretrievably corrupted. c) I roll in a new ldap database from a known good copy. d) Problem is the passwords for the machine accounts are out of date. e) Is it possible to coax Samba & the clients (mostly XP) to resynch their passwords? f) I want to preserve the client computers SIDs & names. g) I really

Hi, I downloaded afew off files from the site (www.vorbis.com) and also downloaded the winamp plugin (dll file), but I am unable to play the off files. -- Ramakrishnan.M | Phone : (+91-80)-5099132 DSP Applications Group, Texas Instruments | email : rkrishnan@ti.com Bangalore, India | rkrishnan_m@yahoo.com ---

On 03/01/2017 05:30 PM, Daniel Berlin via llvm-dev wrote: > So, https://bugs.llvm.org/show_bug.cgi?id=32056 is an example showing > our current TBAA tree for union generation is definitely irretrievably > broken. > I'll be honest here. I'm pretty sure your proposal doesn't go far enough. > But truthfully, I would rather see us come closer to a representation > we

On 13/09/2019 18:30, Christopher Sean Hilton via samba wrote: > On Fri, Sep 13, 2019 at 03:39:44PM +0100, Rowland penny via samba wrote: >> On 13/09/2019 15:34, Marco Gaiarin via samba wrote: >>> Mandi! Rowland penny via samba >>> In chel di` si favelave... >>> >>>>> https://github.com/fumiyas/smbldap-tools >>>> Even that points

Hi, I have just recovered from a ZFS crash. During the antagonizing time this took, I was surprised to learn how undocumented the tools and options for ZFS recovery we''re. I managed to recover thanks to some great forum posts from Victor Latushkin, however without his posts I would still be crying at night... I think the worst example is the zdb man page, which all it does is to ask you

Not familiar with clang enough to know. Staring at it, it looks a bit annoying to do. You'd basically just want to stop decorating loads/stores with tbaa info if it's a union. On Fri, Apr 7, 2017 at 12:09 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can we turn off TBAA info for union member accesses in clang before this > gets fixed? > >