Page 1 of 6 123 ... LastLast
Results 1 to 10 of 55

Thread: Tower's BtrFS has gone ReadOnly... again... yet again.

  1. #1
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Tower's BtrFS has gone ReadOnly... again... yet again.

    Uptime was just a couple of hours short of reaching 6 days, which would have been the first time it reached that threshold instead of its usual freezing or rebooting sometime during the 5th day. Alas, once more it did not make it, but this time it did damage. All temperatures were normal, cpu & RAM usage were low, no external power dip occurred, TW [20171125] had been behaving beautifully. Until...

    ...i needed to go to bed, so i went to Suspend TW. It did not respond. I tried again, thinking my click had not registered. It gave a warning message that a suspend job was already queued [not those exact words], but otherwise ignored me again. Fearing that this was the beginning of another crash, i began closing all my open docs & pgms, preparatory to doing a full shutdown. Each respective window duly closed, but KSysGuard showed their processes still ran [& would not be manually killed when i tried therein]. I tried the Shutdown widget, initially which seemed to work, but then a TTY appeared instead of the desktop, & proceeded to fill with continuous error messages, mentioning that the write job was being ignored due to the read-only file system. Oh noooooooo, not that rotten problem yet again!

    After 15' those errors just continued streaming along in TTY, so i did REISUB, to which it did respond. Upon the reboot all looked normal until i reached the passphrase screen to decrypt my /dev/sda3 & mount my /home. It accepted my passphrase, but almost immediately gave simply a blank screen with blinking top lhs cursor. This was repeatable. Groan.

    Remembering the last time this [read-only filesystem] occurred, & what solved it, https://forums.opensuse.org/showthre...21#post2840121, i attempted the same rescue... booted Tower from my Krypton USB, & tried the btrfs repair. It was not a good outcome this time:
    Code:
    linux@localhost:~> sudo blkid
    /dev/sdc3: LABEL="hybrid" UUID="f232076a-c63b-424b-af27-a7a23b07a49a" TYPE="ext4" PARTUUID="c0bef442-03"
    /dev/sdc2: UUID="2017-07-10-10-52-11-00" LABEL="\"openSUSE Krypton Stable\"" TYPE="iso9660" PARTUUID="c0bef442-02"
    /dev/loop0: TYPE="squashfs"
    /dev/sdb1: UUID="1be44f1e-8593-460e-91ab-c6132245f640" TYPE="crypto_LUKS" PARTUUID="00060756-01"
    /dev/sda1: SEC_TYPE="msdos" UUID="DFF3-1AD7" TYPE="vfat" PARTLABEL="primary" PARTUUID="bde1c356-f603-4a7e-ad42-c399c35f9750"
    /dev/sda2: LABEL="root" UUID="f3e11c85-7f1a-4e9e-8585-5b6a61e4ea8c" UUID_SUB="65ee96ef-42d9-4fe4-b96c-c57e868cc214" TYPE="btrfs" PARTLABEL="primary" PARTUUID="b56c2d68-cc5f-48e7-bbd0-2b981a6c602a"
    /dev/sda3: UUID="a3869823-41e7-498d-abe7-84438db8f4af" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="d2fc8cea-af0e-446f-8a59-264cc59a1451"
    /dev/sdb2: LABEL="SeagateSpare" UUID="f4ae6a8c-a541-4bbd-b086-6358872a3962" TYPE="xfs" PARTUUID="00060756-02"
    /dev/sdb3: LABEL="Seagate" UUID="23927deb-03f4-4b7b-9599-9e44c9f86919" TYPE="ext4" PARTUUID="00060756-03"
    /dev/sdc1: SEC_TYPE="msdos" LABEL="BOOT" UUID="BA91-72AD" TYPE="vfat" PARTUUID="c0bef442-01"
    
    
    linux@localhost:~> sudo btrfs check --repair /dev/sda2
    enabling repair mode
    incorrect offsets 12731 12987
    Checking filesystem on /dev/sda2
    UUID: f3e11c85-7f1a-4e9e-8585-5b6a61e4ea8c
    checking extents
    incorrect offsets 12731 12987
    incorrect offsets 12731 12987
    Unable to find block group for 0
    extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
    btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
    btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
    btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
    btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
    btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
    btrfs(+0x1b000)[0x55fbb265e000]
    btrfs(+0x1c275)[0x55fbb265f275]
    btrfs(+0x1c8b9)[0x55fbb265f8b9]
    btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
    btrfs(main+0x84)[0x55fbb2661e34]
    /lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
    btrfs(_start+0x2a)[0x55fbb2661f4a]
    Unable to find block group for 0
    extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
    btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
    btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]                                                                                                                                           
    btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]                                                                                                                                               
    btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]                                                                                                                                                 
    btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]                                                                                                                                               
    btrfs(+0x1b000)[0x55fbb265e000]                                                                                                                                                              
    btrfs(+0x1c275)[0x55fbb265f275]                                                                                                                                                              
    btrfs(+0x1c8b9)[0x55fbb265f8b9]                                                                                                                                                              
    btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]                                                                                                                                                       
    btrfs(main+0x84)[0x55fbb2661e34]                                                                                                                                                             
    /lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]                                                                                                                                     
    btrfs(_start+0x2a)[0x55fbb2661f4a]                                                                                                                                                           
    Unable to find block group for 0                                                                                                                                                             
    extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1                                                                                                                 
    btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
    btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
    btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
    btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
    btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
    btrfs(+0x1b000)[0x55fbb265e000]
    btrfs(+0x1c275)[0x55fbb265f275]
    btrfs(+0x1c8b9)[0x55fbb265f8b9]
    btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
    btrfs(main+0x84)[0x55fbb2661e34]
    /lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
    btrfs(_start+0x2a)[0x55fbb2661f4a]
    extent-tree.c:2696: btrfs_reserve_extent: BUG_ON `ret` triggered, value -28
    btrfs(+0x2a5f6)[0x55fbb266d5f6]
    btrfs(btrfs_reserve_extent+0x94b)[0x55fbb267283b]
    btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
    btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
    btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
    btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
    btrfs(+0x1b000)[0x55fbb265e000]
    btrfs(+0x1c275)[0x55fbb265f275]
    btrfs(+0x1c8b9)[0x55fbb265f8b9]
    btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
    btrfs(main+0x84)[0x55fbb2661e34]
    /lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
    btrfs(_start+0x2a)[0x55fbb2661f4a]
    Aborted
    linux@localhost:~>
    The only bit of good fortune i had this time, was the surprise discovery that Krypton actually gave me access to my encrypted /home. It was literally as simple as navigating to that partition in Dolphin, clicking on it, & entering my passphrase into the resultant popup dialog box. Thank goodness!. So i have therefore been able to copy all my data to "/dev/sdb2: LABEL="SeagateSpare"" temporarily, & am now [3:10am] going to bed.

    Unless something happens in my dreams to change my mind, tomorrow i shall be ending my five month Tumbleweed dalliance. On both my Tower & Laptop there's just been too many of these stressful serious incidents. TW's Plasma5 runs superbly for a while, then out of the blue has a meltdown & gives me apoplexy, then the pattern repeats. My laptop stopped being TW two weeks ago after its last catastrophe, which lost all data [https://forums.opensuse.org/showthre...2#post2845862]. Tomorrow i regretfully think TW will be over too, for Tower. It's sad.

  2. #2
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    297

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by GooeyGirl View Post
    ... Unless something happens in my dreams to change my mind, tomorrow i shall be ending my five month Tumbleweed dalliance. On both my Tower & Laptop there's just been too many of these stressful serious incidents. TW's Plasma5 runs superbly for a while, then out of the blue has a meltdown & gives me apoplexy, then the pattern repeats. My laptop stopped being TW two weeks ago after its last catastrophe, which lost all data [https://forums.opensuse.org/showthre...2#post2845862]. Tomorrow i regretfully think TW will be over too, for Tower. It's sad.
    No meltdown or even minor annoyances with several installations since one year when using ext4. Btrfs is complex. With the experience gained in those months starting again with ext4 is easy and straight forward.Tumbleweed is rock stable when sticking to KISS.
    Intel i3-4130, ASRock Z87 Pro 3, 16GB DDR3-1600, Samsung 840 EVO 250GB, Seagate ST2000DM001 2 TB (ass. in 2014) Tumbleweed
    Intel i7-6700K, ASRock Z170 Pro 4S, 32GB DDR4-2166, Samsung 950 PRO 512GB, Western Digital WD40EZRX 4 TB (ass. in 2016) Tumbleweed

  3. #3

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    (1) ext4
    (2) really wondering if your hardware is flaky

    Re-install with ext4, and if you are still having problems, you really really need to have a closer look at the hardware. Hardware can be super tricky sometimes, unfortunately. TW is just another distro. You could install any other distro w/btrfs also, and then you'd likely have the same problems. TW is really nice, just admit it, and use ext4 instead.

  4. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    23,244
    Blog Entries
    15

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Hi
    I wonder about the hardware as well, Samsung SSD's have numerous google hits with issues (some are still blacklisted and can have issues with controllers), but also wonder if it's the encryption?

    As other suggest try ext4 and see how it goes?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.2 (x86_64) GNOME 3.20.2
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #5
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Thanks to each of you.

    Re potential Tower hardware root cause of this cumulative episodic pain, obviously i cannot be certain that it's not h/w, but i offer these thoughts to potentially counter that proposition:
    1. I have had TW meltdowns on both Tower and Lappy. The only reason IMO why more of my threads have been for Tower than Lappy, is that Tower is my primary pc & is in constant use day & many nights, whereas Lappy being my secondary pc has much lighter & less frequent use.
    2. In previous threads where opinion had been offered by helpers suspecting my Tower's h/w, each time i ran tests no faults were found.
    3. In my early months of TW i didn't note when many of the frequent TW freezes or self-reboots occurred [those frequent events usually did not (appear to) cause the serious problems like now; the events like now whilst still too many, have been rarer]. However for the past month i have specifically logged when those irritant events [TW freezes or self-reboots] occurred, & the pattern has been amazing. They occur sometime during the 5th Uptime day... sometimes early, sometimes late [like last night, which very nearly made it to 6 days]. So pls help me understand... what kind of hardware defect can lie dormant [else incrementally accumulate] & then only go boom on the 5th day each time? In my mind such cyclic behaviour is more consistent with a s/w-based defect... indeed it's almost like there is some "system resource" which gets depleted slowly & attains the critical threshold each 5th Uptime day.


    Re potential TW BtrFS root cause of this cumulative episodic pain:
    1. In several previous threads of mine, & also sometimes as a comment i've posted in others' threads, i have effusively praised BtrFS, because it allows me to have Snapper, which i think is magically wonderful & a major argument in favour of using TW. Though obviously i still do not know the root cause, i now feel sufficiently beaten down by all these hassles that i can no longer defend BtrFS, & i definitely no longer want to use it [though i acknowledge again that this might not be a BtrFS problem].
    2. But TW was my first-ever rolling release, & a really major part of my deliberations back in June when i investigated it as a candidate distro for me, was Snapper with its fantastic rollback function. I comforted myself with the logic that if TW's frequent rolling upgrades ever broke my system, i could rescue myself via Snapper [& indeed i have done so a few times now]. Hence the prospect of potentially staying today with a new-install TW [instead of replacing it with Manjaro KDE like is on my Lappy since its recent TW catastrophe] but without Snapper [ie, ext4 instead of BtrFS], quite alarms me. My TW metaphor has always been that i feel like i'm high up in the air on a tightrope, but i am safe there because openQA is my safety-harness & Snapper is my strong safety-net. No Snapper, no safety-net...
    3. I accept & acknowledge that some of you have enjoyed solid reliable TW behaviour over the long-term, using ext4 not BtrFS for root. However others [eg, Malcolm, from memory] have written that BtrFS for them has been solidly reliable. Clearly my experience now since June, in two TW machines, has fallen well short of that.



    When i awoke this morning i was determined that i was going to replace Tower's TW with Manjaro KDE [& install Timeshift for a quasi-Snapper capability]. Reading your kind replies has given me pause, albeit i'm probably still 70-30 or maybe 60-40 for leaving still. I will drink more coffee, do more pondering, & make a decision in an hour or two.

  6. #6
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    23,244
    Blog Entries
    15

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Hi
    Well I can only go on using btrfs for years now on SSD's (steered clear of Intel and Samsung) without major hiccups (six machines in daily use), snapper was the beast in the beginning but now is tamed...

    I don't use encryption, so one wonders about that....? No issues with Tumbleweed on the MacBook, but it's not used all the time, mainly for testing packages I build/maintain.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.2 (x86_64) GNOME 3.20.2
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  7. #7
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Thanks Malcolm

    I have decided to give TW ... One. More. Chance. It's installing again now, but with these conditions of my decision:
    1. Though i feel very conflicted about this, i have changed root from BtrFS to ext4. Root remains unencrypted. It's still on the Samsung SSD.
    2. I've continued with [ie, am reusing] my separate LUKS /home, still as xfs, & still on the Samsung SSD.
    3. I accepted the Ruby Installer's nomination of a 2 GB Swap partition at the end of the SSD. I've also made it LUKS.
    4. I have deleted the previous 4 GB LUKS Swap partition on the Seagate HDD.
    5. I've retained my existing ext4 "other" data partitions on the Seagate HDD.
    6. I've mounted tmpfs to /tmp [or vice versa, sigh, i still get muddled on this], & allocated a max of 8 GB of my 32 GB RAM to it [an increase from the previous 2 GB, just in case the historic crashes somehow had anything to do with running out of /tmp space, despite the total absence of any evidence of that].
    7. I have made no other changes to fstab, & post-installation i intend to make no changes to any of the parameters i've historically customised, eg, trim, access time, cache pressure, swappiness et al [this is so that in the event of another meltdown there can be no possibility that it was some dumb error of mine that caused it].
    8. I seriously considered dumping the /home encryption as well as root's BtrFS, but decided to retain LUKS based on (a) the scientific principle of changing only one variable at a time, during experiments, (b) i expect my distro to fully & reliably support /home encryption, & if it cannot, then i'm going to dump the distro not the encryption.
    9. This really is TW's last chance. After today, if there's even one dup that breaks my system in a non-trivial way that i cannot easily rectify [given i now have no Snapper Rollback safety-net, & as far as i currently know there is no TW package for Timeshift], or if there's any ongoing continuation of "5th Day freeze/auto-reboot", & of course if there's one more blue-sky meltdown, then TW will be replaced.


    Fingers crossed.

  8. #8
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    23,244
    Blog Entries
    15

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Hi
    Can build timeshift if you want.... doesn't look like any issues...
    https://github.com/teejee2008/timeshift
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.2 (x86_64) GNOME 3.20.2
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  9. #9
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    297

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by GooeyGirl View Post
    Thanks Malcolm

    I have decided to give TW ... One. More. Chance. It's installing again now, but with these conditions of my decision:
    1. Though i feel very conflicted about this, i have changed root from BtrFS to ext4. Root remains unencrypted. It's still on the Samsung SSD.
    2. I've continued with [ie, am reusing] my separate LUKS /home, still as xfs, & still on the Samsung SSD.
    3. I accepted the Ruby Installer's nomination of a 2 GB Swap partition at the end of the SSD. I've also made it LUKS.
    4. I have deleted the previous 4 GB LUKS Swap partition on the Seagate HDD.
    5. I've retained my existing ext4 "other" data partitions on the Seagate HDD.
    6. I've mounted tmpfs to /tmp [or vice versa, sigh, i still get muddled on this], & allocated a max of 8 GB of my 32 GB RAM to it [an increase from the previous 2 GB, just in case the historic crashes somehow had anything to do with running out of /tmp space, despite the total absence of any evidence of that].
    7. I have made no other changes to fstab, & post-installation i intend to make no changes to any of the parameters i've historically customised, eg, trim, access time, cache pressure, swappiness et al [this is so that in the event of another meltdown there can be no possibility that it was some dumb error of mine that caused it].
    8. I seriously considered dumping the /home encryption as well as root's BtrFS, but decided to retain LUKS based on (a) the scientific principle of changing only one variable at a time, during experiments, (b) i expect my distro to fully & reliably support /home encryption, & if it cannot, then i'm going to dump the distro not the encryption.
    9. This really is TW's last chance. After today, if there's even one dup that breaks my system in a non-trivial way that i cannot easily rectify [given i now have no Snapper Rollback safety-net, & as far as i currently know there is no TW package for Timeshift], or if there's any ongoing continuation of "5th Day freeze/auto-reboot", & of course if there's one more blue-sky meltdown, then TW will be replaced.


    Fingers crossed.
    #6: adds complexity without much benefit. KISS applied to partitioning:

    Code:
    erlangen:~ # cat /etc/fstab
    UUID=96e71675-528a-4474-87de-3eb705c0c145 swap                 swap       defaults              0 0
    UUID=8b190950-c141-4351-9198-7a9592b4fb34 /                    ext4       noatime,acl           1 1
    UUID=704621ef-9b45-4e96-ba7f-1becd3924f08 /home                ext4       noatime,acl           1 2
    # archive
    UUID=f5177cae-4082-44ed-9471-b99030f06866 /home-HDD            ext4       noatime,acl           0 0
    # backup system
    UUID=dbc33c75-0fbb-4619-add6-d204ecf63a43 /Leap-42.3           ext4       ro,noatime,acl        0 0
    erlangen:~ #
    Code:
    erlangen:~ # df -ht ext4
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme0n1p2   32G   15G   16G  49% /
    /dev/nvme0n1p3  407G  155G  251G  39% /home
    /dev/sda3        32G  8.9G   22G  30% /Leap-42.3
    /dev/sda4       3.6T  1.6T  2.0T  45% /home-HDD
    erlangen:~ #
    If NVMe fails detach its cable and the machine will boot into Leap-42.3, thus allowing for a very comfortable disaster recovery. /home is mirrored to /home-HDD with user data being available in case of meltdown of /home and allowing for emergency operation.

    #7: you definitely need trim, verify:

    Code:
    erlangen:~ # systemctl list-timers
    NEXT                         LEFT        LAST                         PASSED        UNIT                         ACTIVATES
    Thu 2017-12-07 00:00:00 CET  17h left    Wed 2017-12-06 05:06:56 CET  1h 10min ago  logrotate.timer              logrotate.service
    Thu 2017-12-07 02:06:00 CET  19h left    Tue 2017-12-05 18:52:55 CET  11h ago       systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Mon 2017-12-11 00:00:00 CET  4 days left Mon 2017-12-04 06:51:20 CET  1 day 23h ago fstrim.timer                 fstrim.service
    
    3 timers listed.
    Pass --all to see loaded but inactive timers, too.
    erlangen:~ # 
    erlangen:~ # journalctl -u fstrim.service 
    -- Logs begin at Tue 2017-01-31 14:09:48 CET, end at Wed 2017-12-06 06:15:22 CET. --
    Dec 04 06:51:20 erlangen systemd[1]: Starting Discard unused blocks...
    Dec 04 06:53:31 erlangen fstrim[5205]: /home: 250.8 GiB (269247569920 bytes) trimmed
    Dec 04 06:53:31 erlangen fstrim[5205]: /: 16.6 GiB (17836232704 bytes) trimmed
    Dec 04 06:53:31 erlangen systemd[1]: Started Discard unused blocks.
    erlangen:~ #
    As displayed in the signature both of my recent machines are running on Samsung SSDs. The 840 showed some degradation in performance and recovered after firmware update. The 850 (10,000h) and 950 (4,000h) are working from the shelf and never exhibited any problems.

    Code:
    erlangen:~ # smartctl -x /dev/nvme0n1
    smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.14.2-1-default] (SUSE RPM)
    Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
    === START OF INFORMATION SECTION ===
    Model Number:                       Samsung SSD 950 PRO 512GB
    Serial Number:                      S2GMNX0H609998K
    Firmware Version:                   1B0QBXX7
    PCI Vendor/Subsystem ID:            0x144d
    IEEE OUI Identifier:                0x002538
    Controller ID:                      1
    Number of Namespaces:               1
    Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
    Namespace 1 Utilization:            229,157,601,280 [229 GB]
    Namespace 1 Formatted LBA Size:     512
    Local Time is:                      Wed Dec  6 06:33:34 2017 CET
    Firmware Updates (0x06):            3 Slots
    Optional Admin Commands (0x0007):   Security Format Frmw_DL
    Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
    Maximum Data Transfer Size:         32 Pages
    
    Supported Power States
    St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
     0 +     6.50W       -        -    0  0  0  0        5       5
     1 +     5.80W       -        -    1  1  1  1       30      30
     2 +     3.60W       -        -    2  2  2  2      100     100
     3 -   0.0700W       -        -    3  3  3  3      500    5000
     4 -   0.0050W       -        -    4  4  4  4     2000   22000
    
    Supported LBA Sizes (NSID 0x1)
    Id Fmt  Data  Metadt  Rel_Perf
     0 +     512       0         0
    
    === START OF SMART DATA SECTION ===
    SMART overall-health self-assessment test result: PASSED
    
    SMART/Health Information (NVMe Log 0x02, NSID 0x1)
    Critical Warning:                   0x00
    Temperature:                        34 Celsius
    Available Spare:                    100%
    Available Spare Threshold:          10%
    Percentage Used:                    0%
    Data Units Read:                    7,335,906 [3.75 TB]
    Data Units Written:                 8,043,907 [4.11 TB]
    Host Read Commands:                 75,794,937
    Host Write Commands:                132,239,677
    Controller Busy Time:               855
    Power Cycles:                       528
    Power On Hours:                     4,356
    Unsafe Shutdowns:                   34
    Media and Data Integrity Errors:    0
    Error Information Log Entries:      254
    Errors occur at boot time and are benign.
    Intel i3-4130, ASRock Z87 Pro 3, 16GB DDR3-1600, Samsung 840 EVO 250GB, Seagate ST2000DM001 2 TB (ass. in 2014) Tumbleweed
    Intel i7-6700K, ASRock Z170 Pro 4S, 32GB DDR4-2166, Samsung 950 PRO 512GB, Western Digital WD40EZRX 4 TB (ass. in 2016) Tumbleweed

  10. #10
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    [Ext4] TW is now reinstalled & running, with all my data still available, but of course none of my pgms... so that takes care of the next few hours for me today. I must say - i was momentarily taken aback at the boot menu screen; something looked "missing" from what it usually has looked like, which of course is true... no Snapper item now... sob, sniff.

    Thanks for the GitHub link Malcolm, that's marvellous.
    Code:
    Other Linux Distributions
    
    Download the .RUN installer from Releases page and execute it in a terminal window:
    sudo sh ./timeshift*amd64.run # 64-bit
    sudo sh ./timeshift*i386.run  # 32-bit
    Installer can be used on the following distribution types:
    
    
    • RedHat based - Fedora, RedHat, Cent OS, etc (supports dnf and yum)
    • Debian based - Debian, Ubuntu, Linux Mint, Elementary OS, etc (supports apt)
    • Arch based - Arch Linux, Manjaro, etc (supports pacman)
    Once i have reinstalled my pgms i shall indeed try my hand at this. It would be lovely if i can have Timeshift in TW, given my loss of Snapper. Not as good, i know, but much better than nothing. Should i be worried that the quote above does not mention SUSE / openSUSE wrt compatibility?

Page 1 of 6 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •