Siduction Forum
Siduction Forum => Experimental => Topic started by: ralul on 2012/07/03, 14:57:17
-
This is not a general Debian issue as Wheezy is stuck with Linux-3.2. But with siduction use of btrfs might become problematic!
I just saw this news while upgrading my Gentoo installation:btrfs-progs-0.19-r3::gentoo
# Joe Peterson <lavajoe@gentoo.org> (02 Jul 2012)
# This old version has become out of sync with kernel btrfs, so is dangerous
# (except for those who have an older kernel and know what they are doing).
# Use of the live build (btrfs-progs-9999) is recommended, since no upstream
# versioning is available, and the live build keeps pace with new kernels.
# See bug #420477
Gentoo "live build" is a notion for compiling directly from upstream git source ...
-
Which kernel version appears with this warning?
Thank ralul.
-
For Debian, could there be a script thrown together for building this package?
-
The bug link https://bugs.gentoo.org/show_bug.cgi?id=420477
tells something about using Linux-3.4
This is why reading it, I thought about you guys!
But myself beware of such an unstable filesystem yet ...
-
I have been running a btrfs filesystem since December, 2010. This is installed on a pair of WD1002FAEX "SATA III" drives, connected to the Marvell 9128 6Gb/s controller on my Asus P6X58D-E system board.
root@imerabox:/# blkid -c /dev/null -o list
device fs_type label mount point UUID
-------------------------------------------------------------------------------------------------------
/dev/sda1 ext4 / bea3a748-3411-4024-acd0-39f3882ddaf9
/dev/sda2 ext4 SDA2 /mnt/SDA2 8cfe2acc-7572-4b45-b25f-ed021bb1d78b
/dev/sdb1 ext4 revodata /mnt/REVODATA ec21f5b3-7fd4-4f4b-af8d-cf787b147ae8
/dev/sdc1 ext2 /boot ac7da829-aebb-46f0-806c-04a4d81a945a
/dev/sdc2 swap <swap> 0d939b7d-48f1-47dd-aebe-77e7bd8c3503
/dev/sdd btrfs (in use) c112ed57-0e33-4d4b-82c9-5c55932c529d
/dev/sde btrfs (in use) c112ed57-0e33-4d4b-82c9-5c55932c529d
Today I checked it:
root@imerabox:/# btrfs filesystem show
failed to read /dev/sr0
Label: none uuid: c112ed57-0e33-4d4b-82c9-5c55932c529d
Total devices 2 FS bytes used 771.37GB
devid 2 size 931.51GB used 519.63GB path /dev/sde
devid 1 size 931.51GB used 519.65GB path /dev/sdd
Btrfs Btrfs v0.19
root@imerabox:/# btrfs filesystem df /mnt/DATA
Data, RAID0: total=964.00GB, used=769.82GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=84.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=37.62GB, used=1.56GB
Metadata: total=8.00MB, used=0.00
I ran
root@imerabox:/# btrfs scrub start /mnt/DATA
scrub started on /mnt/DATA, fsid c112ed57-0e33-4d4b-82c9-5c55932c529d (pid=4572)
(couple of hours later after it finished):
root@imerabox:/# btrfs scrub status /mnt/DATA
scrub status for c112ed57-0e33-4d4b-82c9-5c55932c529d
scrub started at Wed Jul 4 13:47:02 2012 and finished after 3577 seconds
total bytes scrubbed: 772.93GB with 0 errors
So, it seems OK at this point. Probably a good time to back up ....
-
How does btrfs stack up against the existing filesystems as well as ZFS?
-
BTRFS is clearly designed for one target application -- massive, flexible storage. Think of server farms and cluster computing. I don't think it offers any advantage for running an OS -- it is not faster than ext4. It offers multi-device performance very similar to RAID, with no special controllers or drivers, so that makes life simpler. For my 2-drive BTRFS filesystem, I used the default options, which sets metadata to be mirrored (similar to RAID 1) and data to be striped (similar to RAID 0). I have not done any benchmark testing -- you can read in Phoronix and elsewhere how the performance compares to ext4. I have about 750GB of music, videos, images, and docs in my /mnt/DATA filesystem, and it has shown no problems in 18 months. When I first installed it, there was no defrag and no fsck available. The first time I ran scrub (the btrfs version of fsck), it found correctible errors on 13 inodes, and fixed them, and there were zero non-correctible errors. It has never found any more errors, as you see above. I worked through a full defrag one time, which is a 2-step process, and that went fine. But I kinda think it was not necessary, similar to ext4.
I have never tried ZFS -- I can't comment on that one.
-
all what dibl said
plus snapshot feature - this would be interesting for use with Debian sid: All of the troubles gone ...
-
Btrfs does sound promising, and looking forward to trying this on my home NAS once it is rock solid.
Filesystems are quite complex underneath the hood so it must take a lot of time to debug and tune
all what dibl said
plus snapshot feature - this would be interesting for use with Debian sid: All of the troubles gone ...
Would be cool to easily roll back should you mess up a DU or a major bug creeps in.
Testing software would also be a breeze so should something break or that you don't want the app, just roll back!
-
plus snapshot feature - this would be interesting for use with Debian sid: All of the troubles gone ...
Huh -- I had not thought of that, but that is one good reason to run this OS on btrfs.
Hmmm, I think maybe Windows could use btrfs! :twisted:
-
dibl,
Windows dont need this feature, since they have a similar thing in windows 8. And for the records: they have partial backups of systemsettings before updates ages ago. ;)
EDIT: I don't think the so called "Wiederherstellungspunkte" are usable - but i think at the same development level like btrfs. They simply dont work in 8/10 Times.
-
That Ms "Wiederherstellungspunkt" (nobody knows the english word) is something artificial on higher OS level. A Btrfs-snapshot is the original filesystem before the snapshot without any copying - very low level.
-
That Ms "Wiederherstellungspunkt" (nobody knows the english word)
Is that what MS called "System Restore" on Win XP, under the System Tools?
I never knew anyone who saved their Windows system with that junk -- I don't think the viruses respected it. :lol:
-
Wiederherstellungspunkt = Återställningspunkt in Swedish, I don't either know the English word and it never worked for me either ;)
-
plus snapshot feature - this would be interesting for use with Debian sid: All of the troubles gone ...
Huh -- I had not thought of that, but that is one good reason to run this OS on btrfs.
Hmmm, I think maybe Windows could use btrfs! :twisted:
Just what we need..a "system restore" for Linux :lol:
-
System Backup:
cp -a source backup
System Restore:
cp -a backup source
:twisted:
-
Is the time almost upon us that siduction could use something like "apt-btrfs-snapshot" (unfortunately its only a Ubuntu hack at the moment) to manage the rolling back of gnarly dist-upgrades. As valuable as the siduction utlility for managing kernels is, it only solves half of the potential problems associated with dist upgrades.
I'm not a programmer - but I would be happy to test such a feature.
Regards
bad-aptitude
-
if you found one who develop and test this and it work reliable we would be happy to distribute such a package.
EDIT: Reliability is the point. Such a tool should not base on a experimental filesystem.
-
System Backup:
cp -a source backup
I'd suggest a slightly enhanced version of this command:
cp -ax /path/to/<source_partition>/. /path/to/<backup>/
The "-x" option prevents "cp" to dive into linked partitions, and the "/." at the end of the source path makes sure only the content is copied (not the containing folder).
-
good point, i'm a litte bit lazy some times
-
One advantage, using the snapshot feature of BTRFS would have over
cp -a source backup
is the snapshot of a BTRFS directory is effectively a set of hardlinks to the original files. So when taking a snapshot prior to a dist-upgrade on BTRFS, only the files changed by the dist-upgrade are "duplicated". At least that is my understanding of the process.
It would seem that this approach could save a lot of time and space.
-
when btrfs will be stable - in 5 or 10 years - i would eventually agree
-
But isn't stable just "dead"?
-
let me cite from the unix-hater-handbook:
"Sure - the new filesystem will corrupt your data. But look, how fast it is!"
The Clue with btrfs is: I tested it a while ago, it was fucking slow at writes and i decided that i don't like it on my main machines. Imho btrfs is a wonderful thing with netbooks and small notebook - machines, where you mostly need high reading speed. Given that it is reliable and have reliable tools for crash recovery.