On Thu, Nov 01, 2012 at 11:56:18AM +0100, Sander wrote:
> > For now, I'll stick with 3.5.3 for a while to make sure my drive is actually
> > ok (it seems to be afterall), and once I'm happy that it's the case, I'll go
> > back to 3.6.3 with serial console remote logging and try to capture the full
Marc MERLIN wrote (ao):
> That said, it's working fine again for now after I went back to kernel 3.5.3
> (down from 3.6.3). It hasn't been long enough to say for sure, but there is
> a remote possibility that changes in 3.6 actually caused my drive to freeze
> after several hours of use.
> When th
On Wed, Oct 31, 2012 at 10:24:40AM +0100, Sander wrote:
> Marc MERLIN wrote (ao):
> > What happened is that my SSD is craping out and failing to write after
> > a certain number of uptime hours.
>
> What model ssd is that if I may ask?
I had my first one, Crucial C300 just die with all my data ab
Marc MERLIN wrote (ao):
> What happened is that my SSD is craping out and failing to write after
> a certain number of uptime hours.
What model ssd is that if I may ask?
Sander
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@
On Mon, Oct 29, 2012 at 10:48:02AM -0700, Marc MERLIN wrote:
> Then, I figured, I'd try mounting all the active snapshots one per one,
> and they worked:
>
> After that, I was able to mount the root (volid 0) without a crash and
> my filesystem looks fine again.
Ok, I was wrong.
What happened is
First, I used another tool to see how the FS looked like, and maybe in
the hopes of having a list of subvolumes without mounting it:
gandalfthegreat:~# btrfs-calc-size /dev/mapper/bootdsk
Calculating size of root tree
180.00KB total size, 0.00 inline data, 1 nodes, 44 leaves, 2 levels
Calc
