Re: Btrfs/SSD
On Tue, May 16, 2017 at 03:58:41AM +0200, Kai Krakow wrote: > Am Mon, 15 May 2017 22:05:05 +0200 > schrieb Tomasz Torcz <to...@pipebreaker.pl>: > > > > Yes, I considered that, too. And when I tried, there was almost no > > > perceivable performance difference between bcache-writearound and > > > bcache-writeback. But the latency of performance improvement was > > > much longer in writearound mode, so I sticked to writeback mode. > > > Also, writing random data is faster because bcache will defer it to > > > background and do writeback in sector order. Sequential access is > > > passed around bcache anyway, harddisks are already good at that. > > > > Let me add my 2 cents. bcache-writearound does not cache writes > > on SSD, so there are less writes overall to flash. It is said > > to prolong the life of the flash drive. > > I've recently switched from bcache-writeback to bcache-writearound, > > because my SSD caching drive is at the edge of it's lifetime. I'm > > using bcache in following configuration: > > http://enotty.pipebreaker.pl/dżogstaff/2016.05.25-opcja2.svg My SSD > > is Samsung SSD 850 EVO 120GB, which I bought exactly 2 years ago. > > > > Now, according to > > http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo.html > > 120GB and 250GB warranty only covers 75 TBW (terabytes written). > > According to your chart, all your data is written twice to bcache. It > may have been better to buy two drives, one per mirror. I don't think > that SSD firmwares do deduplication - so data is really written twice. I'm aware of that, but 50 GB (I've got 100GB caching partition) is still plenty to cache my ~, some media files, two small VMs. On the other hand I don't want to overspend. This is just a home server. Nb. I'm still waiting for btrfs native SSD caching, which was planned for 3.6 kernel 5 years ago :) ( https://oss.oracle.com/~mason/presentation/btrfs-jls-12/btrfs.html#/planned-3.6 ) > > > > My > > drive has # smartctl -a /dev/sda | grep LBA 241 > > Total_LBAs_Written 0x0032 099 099 000Old_age > > Always - 136025596053 > > Doesn't say this "99%" remaining? The threshold is far from being > reached... > > I'm curious, what is Wear_Leveling_Count reporting? ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 096 096 000Old_age Always - 18227 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 29 177 Wear_Leveling_Count 0x0013 001 001 000Pre-fail Always - 4916 Is this 001 mean 1%? If so, SMART contradicts datasheets. And I don't think I shoud see read errors for 1% wear. > > which multiplied by 512 bytes gives 69.6 TB. Close to 75TB? Well… > > -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs/SSD
On Mon, May 15, 2017 at 09:49:38PM +0200, Kai Krakow wrote: > > > It's worth noting also that on average, COW filesystems like BTRFS > > (or log-structured-filesystems will not benefit as much as > > traditional filesystems from SSD caching unless the caching is built > > into the filesystem itself, since they don't do in-place rewrites (so > > any new write by definition has to drop other data from the cache). > > Yes, I considered that, too. And when I tried, there was almost no > perceivable performance difference between bcache-writearound and > bcache-writeback. But the latency of performance improvement was much > longer in writearound mode, so I sticked to writeback mode. Also, > writing random data is faster because bcache will defer it to > background and do writeback in sector order. Sequential access is > passed around bcache anyway, harddisks are already good at that. Let me add my 2 cents. bcache-writearound does not cache writes on SSD, so there are less writes overall to flash. It is said to prolong the life of the flash drive. I've recently switched from bcache-writeback to bcache-writearound, because my SSD caching drive is at the edge of it's lifetime. I'm using bcache in following configuration: https://enotty.pipebreaker.pl/dżogstaff/2016.05.25-opcja2.svg My SSD is Samsung SSD 850 EVO 120GB, which I bought exactly 2 years ago. Now, according to http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo.html 120GB and 250GB warranty only covers 75 TBW (terabytes written). My drive has # smartctl -a /dev/sda | grep LBA 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 136025596053 which multiplied by 512 bytes gives 69.6 TB. Close to 75TB? Well… [35354.697513] sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [35354.697516] sd 0:0:0:0: [sda] tag#19 Sense Key : Medium Error [current] [35354.697518] sd 0:0:0:0: [sda] tag#19 Add. Sense: Unrecovered read error - auto reallocate failed [35354.697522] sd 0:0:0:0: [sda] tag#19 CDB: Read(10) 28 00 0c 30 82 9f 00 00 48 00 [35354.697524] blk_update_request: I/O error, dev sda, sector 204505785 Above started appearing recently. So, I was really suprised that: - this drive is only rated for 120 TBW - I went through this limit in only 2 years The workload is lightly utilised home server / media center. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.
On Wed, Feb 08, 2017 at 07:50:22AM -0500, Austin S. Hemmelgarn wrote: > It is exponentially safer in BTRFS > to run single data single metadata than half raid1 data half raid1 metadata. Why? > To convert to profiles _designed_ for a single device and then convert back > to raid1 when I got another disk. The issue you've stumbled across is only > partial motivation for this, the bigger motivation is that running half a 2 > disk array is more risky than running a single disk by itself. Again, why? What's the difference? What causes increased risk? -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.7.2 & btrfs & rsync & OOM gone crazy
On Fri, Aug 26, 2016 at 03:00:48PM -0400, E V wrote: > Just upgraded from 4.6.5 to 4.7.2 for my btrfs backup server with 32GB > of ram. Only thing that run's on it is an rsync of an NFS filesystem > to the local btrfs. Cached mem tends to hang out around 26-30GB, but > with 4.7.2 the OOM is now going crazy and trying to kill whatever it > can including my ssh and rsync process. Anyone seen anything similar? That's probably OOM regression in 4.7. Could you please test this patch: https://lkml.org/lkml/2016/8/23/145 -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: errno:28 (No space left on device)
On Tue, Aug 09, 2016 at 01:50:04PM +0200, Thomas wrote: > Hello! > > I'm facing a severe issue with Debian installation using BTRFS: > errno:28 (No space left on device) Sending this message 3x won't make it more important. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs-progs: add option to run balance as daemon
On Mon, Jul 11, 2016 at 07:17:28AM -0400, Austin S. Hemmelgarn wrote: > On 2016-07-11 03:26, Tomasz Torcz wrote: > > On Tue, Jun 21, 2016 at 11:16:59AM -0400, Austin S. Hemmelgarn wrote: > > > Currently, balance operations are run synchronously in the foreground. > > > This is nice for interactive management, but is kind of crappy when you > > > start looking at automation and similar things. > > > > It can be done with simplest systemd unit file: > > btrfs-balance@.service: > > --- > > [Unit] > > Description=btrfs balance for %I > > > > [Service] > > ExecStart=/usr/bin/btrfs balance start %I > > ExecStop=/usr/bin/btrfs balance cancel %I > > --- > > > > It automates quite nicely and needs no additional code. > > > It's also entirely dependent on a couple of things: > 1. You're running systemd (not everyone is, I'm certainly not). So instead of using widespread, tested code, you re-implement parts of it. BTW, your patch for daemonizing does only 5 steps out of 15 described in man 7 daemon. > 2. You're only dealing with the local system. > > The type of situation I'm thinking of is dealing with non-local systems. > For example, running something like this: > ssh user@remotehost btrfs balance start --background / > Keeping the SSH connection open for the duration of the balance has issues > for some people (may close without keep-alive set, uses network bandwidth > with keep-alive set, many people who are hosted have bandwidth quotas > still), and it's extremely useful to have the option to fire and forget. I don't get the local part. Right now, when using above unit you can ssh user@remotehost systemctl start btrfs-balance@- (or even systemctl -H user@remotehost start btrfs-balance@-) and balance for / runs in background on target host. With clean environment, logs being captured, locking against multiple startups and so on. Right now, without any additional code. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs-progs: add option to run balance as daemon
On Tue, Jun 21, 2016 at 11:16:59AM -0400, Austin S. Hemmelgarn wrote: > Currently, balance operations are run synchronously in the foreground. > This is nice for interactive management, but is kind of crappy when you > start looking at automation and similar things. It can be done with simplest systemd unit file: btrfs-balance@.service: --- [Unit] Description=btrfs balance for %I [Service] ExecStart=/usr/bin/btrfs balance start %I ExecStop=/usr/bin/btrfs balance cancel %I --- It automates quite nicely and needs no additional code. -- Tomasz Torcz"Funeral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-btrfs.rules and degraded boot
On Wed, Jul 06, 2016 at 02:55:37PM +0300, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn > <ahferro...@gmail.com> wrote: > > On 2016-07-06 05:51, Andrei Borzenkov wrote: > >> > >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy <li...@colorremedies.com> > >> wrote: > >>> > >>> I started a systemd-devel@ thread since that's where most udev stuff > >>> gets talked about. > >>> > >>> > >>> https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html > >>> > >> > >> Before discussing how to implement it in systemd, we need to decide > >> what to implement. I.e. > >> > >> 1) do you always want to mount filesystem in degraded mode if not > >> enough devices are present or only if explicit hint is given? > >> 2) do you want to restrict degrade handling to root only or to other > >> filesystems as well? Note that there could be more early boot > >> filesystems that absolutely need same treatment (enters separate > >> /usr), and there are also normal filesystems that may need be mounted > >> even degraded. > >> 3) can we query btrfs whether it is mountable in degraded mode? > >> according to documentation, "btrfs device ready" (which udev builtin > >> follows) checks "if it has ALL of it’s devices in cache for mounting". > >> This is required for proper systemd ordering of services. > > > > > > To be entirely honest, if it were me, I'd want systemd to fsck off. If the > > kernel mount(2) call succeeds, then the filesystem was ready enough to > > mount, and if it doesn't, then it wasn't, end of story. > > How should user space know when to try mount? What user space is > supposed to do during boot if mount fails? Do you suggest > > while true; do > mount /dev/foo && exit 0 > done > > as part of startup sequence? And note that nowhere is systemd involved so far. Getting rid of such loops was the original motivation for the ioctl: http://www.spinics.net/lists/linux-btrfs/msg17372.html Maybe the ioctl need extending? Instead of returning 1/0, it could take flag saying ”return 1 as soon as degraded mount is possible”? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Experimental btrfs encryption
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > Warning: > The code is in prototype/experimental stage and is not suitable > for the production data yet. Can you share some design documents? Will it be compatible with existing encrypting filesystems: – ext4 ? – ZFS ? It would be nice to have common API for encryption, not a dozen of filesystem-specific interfaces. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: systemd : Timed out waiting for defice dev-disk-by…
On Fri, Jul 24, 2015 at 02:41:17PM -0400, Vincent Olivier wrote: Hi, (Sorry if this gets sent twice : one of my mail relay is misbehaving today) 50% of the time when booting, the system go in safe mode because my 12x 4TB RAID10 btrfs is taking too long to mount from fstab. When I comment it out from fstab and mount it manually, it’s all good. I don’t like that. Is there a way to increase the timer or something ? man systemd.mount, search for ”x-systemd.device-timeout=”. But maybe that's a hint for developers, long mount time for btrfs are quite common – it would be cool if it could be reduced. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplainable corruptions 3.17.0
On Fri, Oct 17, 2014 at 04:02:03PM +0800, Liu Bo wrote: Does scrub work for you? Scrub ended with not errors: scrub status for a4f339d4-c129-4485-acc1-1233d29c665d scrub started at Fri Oct 17 10:04:24 2014 and finished after 31992 seconds total bytes scrubbed: 6.03TiB with 0 errors I guess I'll have to check the patch Marc pointed out. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplainable corruptions 3.17.0
On Fri, Oct 17, 2014 at 08:53:06AM -0400, Chris Mason wrote: On Fri, Oct 17, 2014 at 4:54 AM, Tomasz Torcz to...@pipebreaker.pl wrote: On Fri, Oct 17, 2014 at 04:29:36PM +0800, Liu Bo wrote: On Fri, Oct 17, 2014 at 10:10:09AM +0200, Tomasz Torcz wrote: On Fri, Oct 17, 2014 at 04:02:03PM +0800, Liu Bo wrote: Recently I've observed some corruptions to systemd's journal files which are somewhat puzzling. This is especially worrying as this is btrfs raid1 setup and I expected auto-healing. read(4, 0x1001000, 65536) = -1 EIO (Input/output error) Well..I don't know exactly what's the cause, but as the file is NOCOW, it writes data in place, have you experienced a hard reboot or something recently? Nothing like that. Server is on an UPS, there were couple normal shutdowns this year (few kernel upgrades). And any message in dmesg log while getting EIO by reading the file? Nothing in dmesg, no btrfs messages, no SCSI/SATA errors, nothing. That's why I find those corruptions mysterious. Maybe there is some way to inspect internal btrfs state and find out what causing the problems? Or maybe this is related to patch mentioned in this thread? This sounds like the problem fixed with some patches to our extent mapping code that went in with the merge window. I've cherry picked a few for stable and I'm running them through tests now. They are in my stable-3.17 branch, and I'll send to Greg once Linus grabs the revert for the last one. But, if you want to try that branch out, it may fix this EIO. Otherwise we'll start sending you debugging. Good shot. Fedora kernel maintainer was kind enough to include those patches and build a kernel for F21. With this kernel EIO is not showing and files are readable. Thanks! -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplainable corruptions 3.17.0
On Fri, Oct 17, 2014 at 11:01:51AM -0400, Chris Murphy wrote: On Oct 16, 2014, at 5:17 AM, Tomasz Torcz to...@pipebreaker.pl wrote: Broken files are in /var/log/journal directory. This directory is set NOCOW with chattr, all the files within too. Example of broken file: system@0005057fe87730cf-6d3d85ed59bd70ae.journal~ What do you get for 'journalctl --verify' ? I'm curious if any journal files are considered corrupt by journalctl, and if there's parity between journalctl and dd_rescue when it comes to good/bad journals. journalctl bus errors on them. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplainable corruptions 3.17.0
On Fri, Oct 17, 2014 at 04:02:03PM +0800, Liu Bo wrote: Recently I've observed some corruptions to systemd's journal files which are somewhat puzzling. This is especially worrying as this is btrfs raid1 setup and I expected auto-healing. System details: 3.17.0-301.fc21.x86_64 btrfs: raid1 over 2x dm-crypted 6TB HDDs. mount opts: rw,relatime,seclabel,compress=lzo,space_cache Reads with cat, hexdump fails with: read(4, 0x1001000, 65536) = -1 EIO (Input/output error) Does scrub work for you? As there seem to be no way to scrub individual files, I've started scrub of full volume. It will take some hours to finish. Meanwhile, could you satisfy my curiosity what would scrub do that wouldn't be done by just reading the whole file? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplainable corruptions 3.17.0
On Fri, Oct 17, 2014 at 04:29:36PM +0800, Liu Bo wrote: On Fri, Oct 17, 2014 at 10:10:09AM +0200, Tomasz Torcz wrote: On Fri, Oct 17, 2014 at 04:02:03PM +0800, Liu Bo wrote: Recently I've observed some corruptions to systemd's journal files which are somewhat puzzling. This is especially worrying as this is btrfs raid1 setup and I expected auto-healing. read(4, 0x1001000, 65536) = -1 EIO (Input/output error) Well..I don't know exactly what's the cause, but as the file is NOCOW, it writes data in place, have you experienced a hard reboot or something recently? Nothing like that. Server is on an UPS, there were couple normal shutdowns this year (few kernel upgrades). And any message in dmesg log while getting EIO by reading the file? Nothing in dmesg, no btrfs messages, no SCSI/SATA errors, nothing. That's why I find those corruptions mysterious. Maybe there is some way to inspect internal btrfs state and find out what causing the problems? Or maybe this is related to patch mentioned in this thread? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
unexplainable corruptions 3.17.0
Hi, Recently I've observed some corruptions to systemd's journal files which are somewhat puzzling. This is especially worrying as this is btrfs raid1 setup and I expected auto-healing. System details: 3.17.0-301.fc21.x86_64 btrfs: raid1 over 2x dm-crypted 6TB HDDs. mount opts: rw,relatime,seclabel,compress=lzo,space_cache Broken files are in /var/log/journal directory. This directory is set NOCOW with chattr, all the files within too. Example of broken file: system@0005057fe87730cf-6d3d85ed59bd70ae.journal~ When read with dd_rescue, there are many I/O errors reported, the summary looks like that (x = error): -..-..x---x.-..-..-...-..-..-...- 100% Reads with cat, hexdump fails with: read(4, 0x1001000, 65536) = -1 EIO (Input/output error) But btrfs dev stat reports no errors! $ btrfs dev stat . [/dev/dm-0].write_io_errs 0 [/dev/dm-0].read_io_errs0 [/dev/dm-0].flush_io_errs 0 [/dev/dm-0].corruption_errs 0 [/dev/dm-0].generation_errs 0 [/dev/dm-1].write_io_errs 0 [/dev/dm-1].read_io_errs0 [/dev/dm-1].flush_io_errs 0 [/dev/dm-1].corruption_errs 0 [/dev/dm-1].generation_errs 0 There are no hardware errors in dmesg. This is perplexing. How to find out what is causing the brokeness and howto avoid it in the future? -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: REPORT: Still a lot of BTRFS freezes in 3.16.1-1-ARCH
On Sun, Aug 24, 2014 at 07:25:43PM +0200, Swâmi Petaramesh wrote: Hi there, This is to report that I'm still having quite systematic BRTFS freezes on an ArchLinux running latest 3.16.1-1-ARCH kernel. Interestingly enough, I have several latops with the exact same setup : Arch Linux with 3.16.1-1-ARCH kernel, fully running on BTRFS (with LZO compression) over LVM over LUKS. Have you applied Liu's patch[1]? It not useful reporting knows bugs, if you haven't. 1 – http://www.spinics.net/lists/linux-btrfs/msg36616.html -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs-progs: fix race condition between btrfs and udev
On Wed, Jun 11, 2014 at 08:11:38PM +0800, Wang Shilong wrote: So the problem is RW opening would trigger udev event which will call btrfs_scan_one_device(). In btrfs_scan_one_device(), it would open the block device with EXCL flag..meanwhile if another program try to open that device with O_EXCL, it would fail with EBUSY. This happen seldomly in the real world, but if we use loop device for test, we may hit this annoying problem. Hi, udev just changed the locking semantics, see description in http://cgit.freedesktop.org/systemd/systemd/commit/NEWS?id=4196a3ead3cfb823670d225eefcb3e60e34c7d95 -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Btrfs: add xxhash algorithm
On Wed, May 07, 2014 at 06:56:29PM +0800, Liu Bo wrote: xxHash is an extremely fast non-cryptographic Hash algorithm, working at speeds close to RAM limits.[1] And xxhash is 32-bits hash, same as crc32. Here is the hash comparsion extracted from the link[1]: (single thread, Windows Seven 32 bits, using Open Source's SMHasher on a Core 2 Duo @3GHz) NameSpeed Q.Score Author xxHash 5.4 GB/s 10 CRC32 0.43 GB/s 9 Core 2 Duo is awfully old CPU. Since 2008, Intel CPUs have crc32 instruction, hugely speeding up CRC operations. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which companies are using Btrfs in production?
On Wed, Apr 23, 2014 at 06:19:52PM -0700, Marc MERLIN wrote: Oh while we're at it, are there companies that can say they are using btrfs in production? Jolla is selling smartphones with btrfs. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Working on Btrfs as topic for master thesis
On Thu, Jan 16, 2014 at 07:23:18PM +, Toggenburger Lukas wrote: Hi all I'm a student of ICT currently doing my master's degree besides working as a research assistant. Currently I'm looking for topics for my master thesis. One of my ideas was to work on Btrfs. I studied the list of project ideas at https://btrfs.wiki.kernel.org/index.php/Project_ideas and am especially interested in working on one of the following topics: Have you considered per-file/per-directory selection of raid level? -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] BTRFS hot relocation support
On Mon, May 06, 2013 at 10:36:03PM +0200, Kai Krakow wrote: zwu.ker...@gmail.com zwu.ker...@gmail.com schrieb: The patchset is trying to introduce hot relocation support for BTRFS. In hybrid storage environment, when the data in HDD disk get hot, it can be relocated to SSD disk by BTRFS hot relocation support automatically; also, if SSD disk ratio exceed its upper threshold, the data which get cold can be looked up and relocated to HDD disk to make more space in SSD disk at first, and then the data which get hot will be relocated to SSD disk automatically. How will it compare to bcache? I'm currently thinking about buying an SSD but bcache requires some efforts in migrating the storage to use. And after all those hassles I am even not sure if it would work easily with a dracut generated initramfs. On the side note: dm-cache, which is already in-kernel, do not need to reformat backing storage. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exploit preload daemon to defragment most needed files
On Sun, May 05, 2013 at 11:42:24AM +0200, Kai Krakow wrote: Hey list, Although this is about the preload daemon, my intended audience for this matter is the btrfs community. So I'm posting this here. I've created a small script here[1] to read the preload daemon state file and use this to run the btrfs defragmenter/compressor on these files. The idea was to have some proof-of-concept to maybe integrate defragmentation capabilities directly into preload. In similar spirit, systemd's readhead defrag files on btrfs. Here's the commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=746f89063666be8c4d538271c646585ac4fc4353 -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs-progs: add skinny metadata support to progs V2
On Fri, Mar 15, 2013 at 02:52:29PM -0400, Josef Bacik wrote: This fixes up the progs to properly deal with skinny metadata. This adds the -x option to mkfs and btrfstune for enabling the skinny metadata option. This also makes changes to fsck so it can properly deal with the skinny metadata entries. Thanks, Can we have a manpage for mkfs.btrfs, explaining what skinny metadata, mixed mode and other *are*? -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Running Apache Derby on 3.8 and BTRFS cause kernel oops
On Thu, Feb 28, 2013 at 03:05:03PM -0500, Josef Bacik wrote: I use the cloud image from here, boot of an Ubuntu CD-ROM ISO to change from ext4 to btrfs, then installed openjdk. http://cloud-images.ubuntu.com/raring/current/raring-server-cloudimg-amd64-disk1.img I could make my image available for download later if you need it, in a pre-failure state. Let me know. Yeah I still can't reproduce, can either of you send me your kernel config so I can see if it's something in my config that's causing problems? Thanks, Josef Yes, here is it Great I'll set this up on both of my boxes and see if I can reproduce. In the meantime will you try btrfs-next? I just pushed a tree-log fix that I don't think will fix your problem but since I don't know what your problem is yet it might, so I'd like to at least eliminate it. Thanks, I put a KVM image up at that you can try: http://www-devel.orcaware.com/blair/btrfs/2013-02-28/ Ok so now that I have it reproducing, how do I go about getting a custom kernel on there? I'm used to libvirt where all the networking stuff is done for me, this doesn't seem to connect to the network at all and it also doesn't seem to have mount.nfs so I can't do what I normally do and mount my local drive as nfs and install the new kernel. What is the best way to go about doing this? You can run start image by invoking qemu-kvm with custom kernel: -kernel bzImage use 'bzImage' as kernel image -append cmdline use 'cmdline' as kernel command line -initrd fileuse 'file' as initial ram disk -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: experimental raid5/6 code in git
Hi, I believe XOR_BLOCKS must be selected, otherwise build fails with: ERROR: xor_blocks [fs/btrfs/btrfs.ko] undefined! diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index 4f5dc93..5f583c8 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -7,6 +7,7 @@ config BTRFS_FS select LZO_COMPRESS select LZO_DECOMPRESS select RAID6_PQ + select XOR_BLOCKS help Btrfs is a new filesystem with extents, writable snapshotting, -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does btrfs adapt to size changes of underlying block device(s)?
On Mon, Feb 04, 2013 at 01:37:21PM +0100, Simon Campese wrote: Hello, I've got a quick question: Does btrfs adapt to size changes of the underlying block device(s)? My specific situation is as follows: I've got a luks-volume on which I want to put btrfs. If this luks-volume grows in the future (i.e. by 'cryptsetup resize'), will btrfs automatically (and reliably) see this and be able to use the additional space? Not automatically, you need to invoke btrfs command for that. But shrinking and growing works online and is reliable. btrfs filesystem resize [devid:][+/-]newsize[gkm]|[devid:]max path -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot mount with acl
On Sat, Feb 02, 2013 at 03:03:48PM -0600, CSights wrote: Hello, btrfs is failing to mount if I use the mount option acl. There is no such option. ACLs are enabled by default, you can only disable them with noacl option. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Old (almost 2 years) btrfs failed fs. Parent transid failure. Can it be fixed ?
On Mon, Oct 29, 2012 at 01:22:59PM +0100, Tommy Jonsson wrote: Hi, i have an old btrfs file-system that crashed on a power-failure for about 2 years ago. i have clone the git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git (at 2012-10-29) and compiled the tools. I think you need to get branch dangerdonoteveruse to get real fsck code. sudo mount -t btrfs /dev/sda /mnt/disk/ Could you try with -o recovery? -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs-progs: mkfs: rename nodiscard option to K
On Tue, Jul 17, 2012 at 11:14:17AM +0200, David Sterba wrote: The original patch named the option -T, mkfs.xfs uses -K let's keep it same. mkfs.ext2 used to have -K also, so one more +1 for this patch. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs filesystems can only be mounted after an unclean shutdown if btrfsck is run and immediately killed!
On Fri, Jun 08, 2012 at 11:26:21AM +0300, Konstantinos Skarlatos wrote: Hi all, I have two multi-disk btrfs filesystems on a Arch linux 3.4.0 system. After a power failure, both filesystems refuse to mount Multi-device filesystem had to be first fully discovered by btrfs device scan. It is typically done from udev rules. Also, dracut does it in initramfs for quite a long time. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SSD format/mount parameters questions
On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote: I would not buy anything else than intel. I have about 26 of them for years now (both in servers and workstations, several series), and never had an issue. Two of my colleagues have OCZ, and both had to RMA them. I guess it boils down wether you want intel also to rule the SSD market in the long term, as they do with PC processors... Comparing intel SSDs with OCZ is not that fair, as OCZ has always been low-priced bleeding edge stuff. Looking into the controllers... first there were bunch of different ones; Intel had it own design with SSD 320. Then come Sandforce; it got broadly used, despite sucking when used with FDE. Even Intel started to used Sandforce - SSD 520. How's reliabilty of Intel differs? Latest fad is Marvell controller; again Intel joins the pack with SSD510. So, Intel is not that different anymore. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS RAID
On Fri, May 04, 2012 at 09:46:15AM -0500, Michael Bailey wrote: Greetings, I have a few questions pertaining to BTRFS RAID. I know it's been rumored a lot recently that kernel 3.4 will have RAID5/6 support, is this still the case. It seem to be wrong. Chris Mason hinted that RAID5/6 will hit kernel 3.5. It is way to late to have it in 3.4. Also, is it possible to change from a single drive system to a raid system or even a multi drive system without raid to a raid system while there is data on the drives an successfully convert them without loosing data? Thank you for any help you can provide. Restriping had landed, so it should be doable. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Allow for quick removing of btrfs signature from block device
On Tue, May 01, 2012 at 02:38:01PM +0200, Hubert Kario wrote: This patch series adds `btrfs device zero super dev` command to remove the btrfs signature from the device as well as fix few minor problems in btrfs_prepare_device function. Shouldn't you rather extend “wipefs” from util-linux? -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Encryption implementation like ZFS?
On Fri, Dec 30, 2011 at 01:27:43PM -0600, Billy Crook wrote: On Fri, Dec 30, 2011 at 12:32, Sandra Schlichting littlesandr...@gmail.com wrote: According to [0] ZFS does encryption: One exception to this is the encryption support being added to the ZFS filesystem. Filesystem metadata such as filenames, ownership, ACLs, extended attributes are all stored encrypted on disk. The ZFS metadata about the storage pool is still stored in the clear so it is possible to determine how many filesystems (datasets) are available in the pool and even which ones are encrypted but not what the content of the stored files or directories are. How is this advantageous over dmcrypt-LUKS? For example mixing encrypted and not encrypted subvolumes in one pool. And not having to separately cryptsetup luksOpen all disks consisting filesystem. There are advantages of FDE like dm-crypt and selective encryption like in ZFS. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot Deinstall a Debian Package
On Fri, May 06, 2011 at 01:04:28PM -0700, cac...@quantum-sci.com wrote: Anyone here? Could you create link from you root parition to /dev/root and try again? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: minor ID for btrfs-control
On Sat, Apr 02, 2011 at 06:45:00PM +0200, Helmut Hullen wrote: if I've understood some mails in this list correct, then btrfs needs a character device btrfs-control with the ID 10:55 When I look for this device in /sys/class/misc/btrfs-control/dev I see 10:234 Kernel 2.6.38.1 (self made), no udev, no initrd, no tempfs. btrfs from nov. 2010 What goes wrong? No udev is wrong. Modern Linux kernels allocate minor devices dynamically. If you do not use udev, you need to synchronise /dev/ node with /sys/class/misc/btrfs-control/dev manually on each boot. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Shrinking virtual disk with btrfs on it
On Fri, Jan 21, 2011 at 07:43:47PM +, David Pottage wrote: On 21/01/11 17:20, Rodney Beede wrote: Any tools to go about zeroing about the free space on a btrfs file system so I can shrink the VMware vmdk virtual disk? I ran the VMware command, but the dynamic disk is still really big. I presume it is due to free space that isn't zeroed out. Does btrfs issue TRIM commands to the underlying (virtual) block device? It does when mounted with - o discard. IIRC, btrfs also supports FITRIM ioctl (but I'm not 100% sure about this). -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SSD optimizations
On Mon, Dec 13, 2010 at 05:17:51PM +, Paddy Steed wrote: So, no-one has any idea's on how to implement the cache. Would making it all swap work, does to OS cache files in swap? Quite the opposite. Too many people have ideas for SSD-as-cache in Linux, in non particular order: — bcache — cleancache — btrfs temperature tracking — dm-hstore — dm-cache / flashcache Patches are in various states of implementation, some with explicit btrfs support. There's no clear winner at this time, but some of above solutions are shipped in distro kernels. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VFS support for fast copy on deduplicating FSes
On Thu, Nov 25, 2010 at 04:19:17AM -0600, David Nicol wrote: unresearched question/suggestion: Is there general support for a fast copy ioctl in the VFS layer, which would be hooked by file systems that support COW or other forms of deduplication and can provide copy semantics by manipulating metadata only? Yes, see reflink(2) syscall (http://lwn.net/Articles/331576/). -- Tomasz TorczFuneral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening. - Alan Cox -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Control filesystem balances (kernel side)
On Mon, Nov 01, 2010 at 01:58:21PM +0100, Xavier Nicollet wrote: Le 30 octobre 2010 à 19:44, Goffredo Baroncelli a écrit: I like the idea that these info should be put under sysfs. Something like /sys/btrfs/filesystem-uuid/ balance- info on balancing devices- list of device (a directory of links or a file which contains the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Well, mdstat stats are under /proc/mdstat. Is sysfs the ideal place ? mdstats are in sys: /sys/block/md127/md/ sync_action, sync_completed, sync_speed, reshape_position etc. /proc file is legacy. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: converting one-disk btrfs into RAID-1?
On Tue, Oct 12, 2010 at 11:32:07AM +0200, David Brown wrote: On 11/10/2010 19:06, Chris Ball wrote: Hi, Is it possible to turn a 1-disk (partition) btrfs filesystem into RAID-1? Not yet, but I'm pretty sure it's on the roadmap. - Chris. Is it possible to view the raid levels of data and meta data for an existing btrfs filesystem? It's easy to pick them when creating the system, but I couldn't find any way to view them afterwards. btrfs f df will show them, except for few kernel releases when the ioctl() was broken. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: converting one-disk btrfs into RAID-1?
On Tue, Oct 12, 2010 at 10:49:35AM +0100, Hugo Mills wrote: On Tue, Oct 12, 2010 at 11:34:31AM +0200, Tomasz Torcz wrote: On Tue, Oct 12, 2010 at 11:32:07AM +0200, David Brown wrote: Is it possible to view the raid levels of data and meta data for an existing btrfs filesystem? It's easy to pick them when creating the system, but I couldn't find any way to view them afterwards. btrfs f df will show them, except for few kernel releases when the ioctl() was broken. Umm... h...@vlad:~ $ sudo btrfs fi df /mnt/ [sudo] password for hrm: Data: total=303.01GB, used=302.16GB Metadata: total=3.01GB, used=476.77MB System: total=11.88MB, used=36.00KB This is the latest btrfs git kernel and tools. What should I be seeing here? Do you have this patch applied? http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06239.html -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about specific patch (eMMC)
On Tue, Aug 31, 2010 at 02:57:05PM +0300, Alexander Vdovichev wrote: Hello all, Is there any patches for btrfs to use enhanced area in eMMC (it will allow to boost performance i.e. it very useful to keep metadata within this area) ? If it's exist let me know how to find it and use it. I'm not aware of this at the moment. However, there are data-temperature tracking patches. Their point is to move hot data into faster storage. I believe they can grow into generic infrastructure to inform filesystems about non-homogenous nature of underlaying storage. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Btrfs-progs: Add hot data support in mkfs
On Fri, Aug 13, 2010 at 05:14:22PM +0400, Andrey Panin wrote: On 224, 08 12, 2010 at 05:29:37PM -0500, bchoc...@gmail.com wrote: From: Ben Chociej bchoc...@gmail.com Modified mkfs.btrfs to add hot data relocation option (-h) which preallocates BTRFS_BLOCK_GROUP_DATA_SSD and BTRFS_BLOCK_GROUP_METADATA_SSD at mkfs time for future use by hot data relocation code. Also added a userspace function to detect whether a block device is an SSD by reading the sysfs block queue rotational flag. IMHO this policy is too inflexible. What if I have large array of slow SATA disks and some fast SAS ones ? I'm hoping that this is just first cut, and future versions will have options. For now, it is totally unusable without a way of using mirrored SSD for hot data. Ideally, hot storage devices should be online selectable and changeable. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of BTRFS
On Fri, Jul 16, 2010 at 08:14:49AM -0400, Edward Ned Harvey wrote: From: Sebastian 'gonX' Jensen [mailto:g...@overclocked.net] On 16 July 2010 13:55, Edward Ned Harvey ker...@nedharvey.com wrote: Is this a good place to get a clue about the status of BTRFS? Like ... Is it usable yet, and stuff like that? It has been in a good state for quite a while. There seems to be quite a lot of people who use it on enterprise-grade hardware and servers that require high reliability. Is it included in any distributions yet? Do you just need to build the latest kernel or something like that? Download the source code, and follow what it says in the INSTALL file? Of course it is. Fedora installer allows btrfs since for few releases now. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to un degrade RAID10.
On Mon, Jun 21, 2010 at 03:43:02PM +1000, ibm-m...@tpg.com.au wrote: Did a (normal, non-RAID) mkfs on the partition, then attempted to add it back as per the wiki. Won't mount without the degraded option even though the 4 partitions are accepted o.k, and a re-balance worked. The array now reports as 5 devices with #2 (the original slot for sda8) now vacant - dare I say missing. It reports as *** Some devices missng This seems counter intuitive to me. Suggestions ?. You can pass missing to btrfs device delete. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mounting raid without a btrfsctl scan
On Sat, May 15, 2010 at 06:47:22PM +0200, Sebastian 'gonX' Jensen wrote: Would it be possible and feasible to support mounting btrfs raid/multi-device filesystems without having to run 'btrfsctl -a'? Currently, as you may know, if a one wants to attach a btrfs raid filesystem to a system (usb, hotswap, reboot, etc), the user or program has to run: btrfsctl -a (or similar) mount /dev/sdb1 /mount/point While this works, it will require patching of various subsystems involved with managing disks, such as udev, mkinitrd, dracut, hal, and others. Each one will have to know to scan, then mount. In a my previous post ([RFC] btrfs, udev and btrfs - 16/April 2010), I suggested a solution for this kind of problem. I a Debian/Ubuntu system it is not necessary to patch anything, it is only required to put some files in the initramfs-tool configure directories. IIRC, also the md (RAID) subsystem require a scan from the user space to find and activate the volumes. I think also dm (LVM) subsystem requires the same. md does not require a scan from userspace with at least both RAID-0 and RAID-1. There's a setting in the kernel config you can set, which will automatically detect all RAID drives with the FD partition flag set. DM may however be true. MD will only detect RAID on MS-DOS partitions (seldom used when RAIDing whole devices, not possible to use with devices 2 TiB) and metadata 0.90, which is not default. Userspace probing is general way kernel subsystem are going, it is more flexible. And dracut already has btrfs module. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iscsi target cause kernel oops on btrfs
On Thu, May 06, 2010 at 10:30:31PM -0700, jason chan wrote: Hi all, I have OpenSUSE and the following rpms: iscsitarget-kmp-desktop-1.4.19_2.6.34.0_rc5_6-2.13.i586 iscsitarget-1.4.19-2.13.i586 May 6 22:11:18 aopen kernel: [ 1201.903664] [c02fcd05] ? do_sync_write+0xb5/0xf0 May 6 22:11:18 aopen kernel: [ 1201.903675] [c023b688] ? dequeue_entity+0x38/0x1f0 May 6 22:11:18 aopen kernel: [ 1201.903687] [f80dd71e] ? fileio_make_request+0x11e/0x200 [iscsi_trgt] I saw it before: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02713.html Never really debugged issue, I've moved to userspace iSCSI implementation, which works fine. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raild[56] again
On Mon, May 03, 2010 at 10:02:10PM +0200, Roy Sigurd Karlsbakk wrote: Hi all Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet Look again, there was an email just few days ago: 3705 Apr 29 David Woodhouse ( 13K) Updating RAID[56] support -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) pgpapzVu6MwL7.pgp Description: PGP signature
Re: [RFC] btrfs, udev and btrfs
On Fri, Apr 16, 2010 at 08:48:14PM +0200, Goffredo Baroncelli wrote: NOTE: I tested these scripts which an ubuntu 10.4 system. I don't know the changes which may be required to work for other distributions (like fedora), but I am very interested in knowing those. Just few days ago I've asked dracut guys for including btrfs support. Current result is here: http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=tree;f=modules.d/90btrfs It still being polished a little. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to handle kernel NULL pointer dereference at virtual address 00000008
On Thu, Jan 21, 2010 at 07:07:10AM +0100, Sander wrote: [26678.568532] [c026c294] (btrfs_get_acl+0x60/0x250) from [c026c494] (btrfs_xattr_get_acl+0x10/0x70) [26678.577802] [c026c494] (btrfs_xattr_get_acl+0x10/0x70) from [c019bb20] (generic_getxattr+0x78/0x7c) [26678.587243] [c019bb20] (generic_getxattr+0x78/0x7c) from [c019c01c] (vfs_getxattr+0x58/0x5c) [26678.596074] [c019c01c] (vfs_getxattr+0x58/0x5c) from [c019c0c4] (getxattr+0xa4/0x11c) [26678.604298] [c019c0c4] (getxattr+0xa4/0x11c) from [c019c220] (sys_getxattr+0x44/0x58) [26678.612525] [c019c220] (sys_getxattr+0x44/0x58) from [c0122e20] (ret_fast_syscall+0x0/0x28) Although your oops is in btrfs_get_acl(), you may need similar fix as done for btrfs_set_acl() in this commit: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commitdiff;h=a9cc71a60c29a09174bee2fcef8f924c529fd4b7 -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to mount a subvolume?
On Sat, Jan 09, 2010 at 03:07:57PM +0100, Dipl.-Ing. Michael Niederle wrote: I read that the current tools cannot display subvolumes, but one should still be able to mount them. If I try I get an error message: mount -t btrfs -o subvol=root.2010-01-07 /dev/sda3 /save mount: /dev/sda3 is not a valid block device root.2010-01-07 is a snapshot of the /root-directory taken (successfully) with the following command: btrfsctl -s root.2010-01-07 /root Snapshots aren't subvolumes. You create mountable subvolumes with btrfsctl -S -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: yum upgrade on btrfs very slow
On Mon, Oct 26, 2009 at 05:55:45PM +0900, Chris Mason wrote: On Wed, Oct 21, 2009 at 11:27:33AM +0200, Tomasz Torcz wrote: On Thu, Oct 01, 2009 at 11:01:46AM +0200, Tomasz Torcz wrote: On Wed, Sep 30, 2009 at 09:43:51PM +0200, Tomasz Torcz wrote: If you're comparing w/ext3 and wondering why btrfs is sooo much slower it might be because btrfs has barriers on by default and ext3 doesn't. You could mount -o nobarrier for btrfs or mount -o barrier=1 for ext3 for a proper comparison. Last update: things got noticably faster with 2.6.31.4-88.fc12.x86_64, which contains backport of latest mainline btrfs (thank you, Josef!). No more comlains from me (for now ;). Fantastic. Are you running with or without barriers now? I stick to default settings, that means barriers I think. Overall, my test hardware is so slow by itself, that barriers are not really noticable. (It's 3 GHz Pentium 4 in 64 bit with single IDE 20GB drive). -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: yum upgrade on btrfs very slow
On Wed, Sep 30, 2009 at 09:43:51PM +0200, Tomasz Torcz wrote: If you're comparing w/ext3 and wondering why btrfs is sooo much slower it might be because btrfs has barriers on by default and ext3 doesn't. You could mount -o nobarrier for btrfs or mount -o barrier=1 for ext3 for a proper comparison. (Assuming your dmesg doesn't have messages from btrfs about disabling barriers). I wouldn't expect barriers to work here (reminder, this is PATA drive on ICH7 sata controller), but I will test tomorrow with nobarrier. Then I probably check his yum upgrade under seekwatcher on friday. Nobarrier result are here: http://pipebreaker.pl/dump/sysrq_w-nobarrier.txt.bz2 http://pipebreaker.pl/dump/vmstat-nobarrier.txt.bz2 My observation: still slow. Just a note on my unscientific methodology: I've got two very similar machines with Rawhide, one on ext4, second on btrfs. Every day I do yum upgrade on both. Ext4 one finishes much faster thatn btrfs. This is especially visible while yum is in cleanup phase. On ext4 most packages are cleaned'up in under one second time. On btrfs this takes few seconds. Whole transaction ends in couple of minutes on ext4. On btrfs it takes 5x longer. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: yum upgrade on btrfs very slow
On Mon, Sep 28, 2009 at 09:35:43AM -0400, Chris Mason wrote: On Mon, Sep 28, 2009 at 02:18:27PM +0200, Tomasz Torcz wrote: Hi, I'm using btrfs as rootfs on my Fedora 12 (rawhide) test system. Every yum activity is very slow, like 15 minutes for installation of 11 packages 25MB in size. Kernel is 2.6.31.1-48.fc12.x86_64, btrfs-progs-0.19-7.fc12.x86_64. Hardware is pentium 4 3.0 GHz (Hyperthreading, 64 bit), with single IDE disk on Intel ICH controller. You're doing quite a lot of reads, and some writes. Could you please capture the output of sysrq-w at 5s intervals during the upgrade? It got quite big (over 100 KiB, over 1 MiB after unpacking), so I put it at http://pipebreaker.pl/dump/sysrq-w_every_5_sec.txt.bz2 -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
yum upgrade on btrfs very slow
] [k] free_kmem_cache_cpus 0.27% perf.2.6.31-33. [kernel] [k] btrfs_set_device_sector_size [btrfs] 0.26% yum-complete-tr [kernel] [k] _raw_read_unlock 0.25% perf.2.6.31-33. [kernel] [k] _spin_lock_bh 0.25% yum-complete-tr [kernel] [k] btrfs_drop_extents [btrfs] 0.23% perf.2.6.31-33. [kernel] [k] btrfs_comp_cpu_keys [btrfs] 0.23% yum-complete-tr /lib64/libc-2.10.90.so [.] __GI_memcpy -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| procs ---memory-- ---swap-- -io --system-- -cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 0 1 31876 14724 28 470292027544 134 129 2 2 88 8 0 0 1 31876 14528 28 47067600 384 0 266 412 0 2 50 49 0 0 1 31876 14196 28 47100400 336 0 265 390 1 1 50 48 0 0 1 31876 14204 28 47126400 296 7668 1142 614 5 27 29 40 0 0 1 31876 11600 28 47214000 872 0 515 586 0 6 50 44 0 0 1 31876 11104 28 47269600 516 0 469 467 0 4 52 43 0 0 1 31876 10732 28 47310000 408 0 481 450 1 5 51 43 0 2 1 31876 10236 28 47349200 392 0 458 491 1 4 49 46 0 1 0 31876 9864 28 47384800 356 0 412 450 1 5 49 46 0 0 1 31876 9368 28 47441600 568 0 456 547 1 4 48 46 0 0 1 31876 8872 28 47484000 424 0 428 504 1 4 48 46 0 0 1 32184 10828 28 4722240 308 400 308 752 527 1 8 47 45 0 0 1 32184 10456 28 47273200 504 0 475 495 0 4 51 44 0 0 1 32184 9712 28 47345200 720 0 493 579 0 5 50 44 0 0 3 32412 10164 28 4726680 228 392 1860 1008 1372 0 10 28 62 0 0 2 32412 10208 28 47289200 200 240 448 629 0 3 21 76 0 0 2 32412 10320 28 47302800 136 8 216 373 0 1 23 75 0 0 1 32412 10072 28 47331600 304 0 387 452 1 3 37 58 0 0 1 32412 9576 28 47377200 448 0 447 546 0 4 49 46 0 1 0 32496 9584 28 4738720 84 108884 787 814 0 8 48 43 0 0 1 33076 9748 28 4730480 580 492 580 1162 532 1 15 46 38 0 procs ---memory-- ---swap-- -io --system-- -cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 0 1 33108 10732 28 4724160 32 49232 574 530 1 6 49 44 0 1 0 33108 9676 28 47260000 140 0 1650 309 29 10 50 12 0 2 0 33772 9212 28 4685280 664 8 3420 2553 414 41 21 38 0 0 1 0 34260 8960 28 4681880 48816 488 2533 194 18 36 44 2 0 0 1 34284 10020 28 4675320 243292 1688 243 14 26 50 10 0 1 0 35940 10020 28 4632000 1656 8 1740 2469 326 14 29 41 16 0 2 0 37652 13964 28 4430760 1712 124 1712 3769 565 25 41 31 3 0 1 0 37652 12512 28 44336400 0 640 2065 231 33 22 46 0 0 1 0 38068 9692 28 4401080 416 0 416 2647 356 38 22 41 0 0 1 0 38652 8948 28 4341440 584 0 584 2699 427 45 16 40 0 0 1 0 38664 9228 28 4336600 12 012 2131 304 45 9 46 0 0 0 1 38664 27800 28 43124000 0 612 1521 579 20 15 47 18 0 0 1 38664 27808 28 43102000 4 1624 516 495 0 14 46 41 0 0 1 38664 28056 28 43086000 4 1624 1391 1417 1 33 38 28 0 0 1 38664 27776 28 43142400 360 108 208 273 0 2 49 49 0 0 1 38664 27320 28 43183200 164 740 526 653 1 9 48 43 0 0 1 38664 25828 28 43327600 1480 0 283 388 0 2 50 49 0 1 1 38664 25668 28 43360400 180 308 490 615 0 6 49 45 0 1 1 38664 25088 28 43383600 148 684 677 642 4 7 49 41 0 0 1 38664 24964 28 4340560068 460 379 460 0 3 50 47 0 0 1 38664 24216 28 43460400 548 0 292 379 0 1 50 49 0 procs
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 07:10:06PM +0200, Markus Trippelsdorf wrote: 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A 4B = 01001011 0B = 1011 And so on. It looks like a few bits are getting flipped at the same byte offset. One can imagine software bugs that would do this, certainly, but upset hardware seems awfully likely too. I'm afraid you're right. I did some further tests and now I'm pretty sure that a bad RAM module was the root cause of it all... Oh well. On the other hand, that what's so great in checksumming filesystems. You found bad module thanks to btrfs, otherwise you wouldn't suspect anything wrong. If you have had raid-1 for data, this corruption would have been fixed by btrfs. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs not iSCSI-target safe?
On Wed, Jul 22, 2009 at 10:40:31AM -0400, Chris Mason wrote: On Wed, Jul 22, 2009 at 01:27:06PM +0200, Tomasz Torcz wrote: Hi, I tried to export file from btrfs volume using iSCSI target. As soon as some initiator have read it over network, server oopsed: http://www.kerneloops.org/submitresult.php?number=557979 Kernel is Fedora's 2.6.29.6-213.fc11.x86_64. I'm aware that target iSCSI functionality is out-of-tree (I'm using iscsitarget-0.4.17-3), so it may not be safe. But is there any known incompatibility between iscsi-target and btrfs? Sorry, I don't know of any problems between btrfs and iscsi. Is the iscsi target configured to use linux aio? That could be the problem. I'm not sure, I'm a mere user. This target software seems to read files from kernelspace, which as I understand is frowned upon. If you are interested, sourcecode is at http://iscsitarget.sourceforge.net/ Ooops occured in fileio_make_request(), in iscsitarget-0.4.17/kernel/file-io.c file. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs not iSCSI-target safe?
Hi, I tried to export file from btrfs volume using iSCSI target. As soon as some initiator have read it over network, server oopsed: http://www.kerneloops.org/submitresult.php?number=557979 Kernel is Fedora's 2.6.29.6-213.fc11.x86_64. I'm aware that target iSCSI functionality is out-of-tree (I'm using iscsitarget-0.4.17-3), so it may not be safe. But is there any known incompatibility between iscsi-target and btrfs? Full oops follows: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [(null)] (null) PGD 311fb067 PUD 31d8d067 PMD 0 Oops: 0010 [#1] SMP last sysfs file: /sys/devices/pci:00/:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda2/stat CPU 1 Modules linked in: iscsi_trgt fuse tun sit tunnel4 sco bridge stp llc bnep l2cap bluetooth sunrpc nf_conntrack_ftp nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi cpufreq_ondemand acpi_cpufreq freq_table btrfs zlib_deflate libcrc32c dm_multipath uinput ppdev dcdbas snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer i2c_i801 snd pcspkr serio_raw iTCO_wdt soundcore snd_page_alloc e100 iTCO_vendor_support mii parport_pc parport tg3 joydev ata_generic pata_acpi sha256_generic cbc aes_x86_64 aes_generic dm_crypt i915 drm i2c_algo_bit i2c_core video output [last unloaded: iscsi_trgt] Pid: 5278, comm: istiod1 Not tainted 2.6.29.6-213.fc11.x86_64 #1 OptiPlex GX620 RIP: 0010:[] [(null)] (null) RSP: 0018:8800bf4e1c98 EFLAGS: 00010286 RAX: a01e5d20 RBX: 8800bf4e1ca0 RCX: RDX: 0001 RSI: 8800bf4e1d90 RDI: 8800bf4e1ca0 RBP: 8800bf4e1dc0 R08: 8800bf4e R09: 880001035d00 R10: 00c601b64c57 R11: 880062489dc0 R12: 8800bf4e1df8 R13: 88003103df00 R14: 8800bf4e1d90 R15: FS: () GS:8800dde99100() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 8296e000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process istiod1 (pid: 5278, threadinfo 8800bf4e, task 88004745) Stack: 810d4eee 81038bc0 8800626f0038 0001 88003103df00 88004745 Call Trace: [810d4eee] ? do_sync_write+0xe8/0x125 [81038bc0] ? wakeup_preempt_entity+0x3d/0x49 [8105c8d7] ? autoremove_wake_function+0x0/0x39 [8103a0e9] ? __dequeue_entity+0x33/0x38 [a03bc024] fileio_make_request+0x14b/0x1dd [iscsi_trgt] [a03b511e] tio_write+0x4f/0x51 [iscsi_trgt] [a03bc93a] build_write_response+0x97/0xb5 [iscsi_trgt] [a03b81f6] send_scsi_rsp+0x15/0xaf [iscsi_trgt] [a03bc7f2] disk_execute_cmnd+0x171/0x19b [iscsi_trgt] [a03b9909] worker_thread+0xb5/0x183 [iscsi_trgt] [8104057d] ? default_wake_function+0x0/0x14 [a03b9854] ? worker_thread+0x0/0x183 [iscsi_trgt] [8105c541] kthread+0x4d/0x78 [8101264a] child_rip+0xa/0x20 [81011f67] ? restore_args+0x0/0x30 [8105c4f4] ? kthread+0x0/0x78 [81012640] ? child_rip+0x0/0x20 Code: Bad RIP value. RIP [(null)] (null) RSP 8800bf4e1c98 CR2: ---[ end trace 9e41df932c81a801 ]--- -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using SSDs for caching?
On Thu, Jun 18, 2009 at 03:56:23PM +0200, Roy Sigurd Karlsbakk wrote: I have heard/read about systems from Sun and NetApp using SDs for caching. Sun uses different SDs for read and write caching (one being faster for reads and the other for writes). The storage solution from Sun is based on Solaris with ZFS. I know too little about filesystems design to know exactly how they do this, but can someone think of a way this could be implemented in btrfs? Linux already has second-level¹ cache layer, it called FS-Cache. For now, the sole user is NFS. btrfs could take advantage of FS-Cache also. ¹ first-level is page cache in RAM -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Btrfs development plans
On Mon, Apr 20, 2009 at 10:37:33AM -0400, Chris Mason wrote: Hello everyone, Just a quick note about the recently announced purchase of Sun by Oracle. This does not change Oracle's plans for Btrfs at all, and Btrfs is still a key project for us. But now Oracle can re-license Solaris and merge ZFS with btrfs. Just kidding, I don't think it would be technically feasible. (OTOH, acquiring Sun's patent portfolio… there are some strange places on earth where people care about software patents). -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crc32c implementation on x86 with SSE4.2... CONFIG_BTRFS_HW_SUM
Dnia 2008-10-16, czw o godzinie 09:49 -0400, Chris Mason pisze: On Thu, 2008-10-16 at 14:40 +0100, Miguel Sousa Filipe wrote: Hi there, I noticed that btrfs, in the git tree, has its own implementation of crc32c for x86 with SSE4.2 that implement a crc32 instruction.. it appears. I don't see intel's patches in mainline yet, but I know there was a plan to get them there. It seems to be merged: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8cb51ba8e06570a5fff674b3744d12a1b089f2d0 Using generic, replaceable by arch version is surely better. This way you can avoid implementing crc32 for each architecture (like, for example UltraSPARC T2, which computes crc at healthy 48 GB/s). -- Tomasz Torcz -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: single disk reed solomon codes
Dnia 2008-07-19, sob o godzinie 17:18 +0200, Gerald Nowitzky pisze: In the end, you would add very little security by the price of -at least- cutting half your write performance. Thus, I don't think there is any point in adding redundancy to single disk systems. ZFS can store multiple copies of data block within one disk. Using your words, it's like Intra-Disk-RAID1. After reading data, when checksum shows it's corrupted, another copy (hopefully correct) is read from other disk location. This is adding security by the price of half storage capacity. Which seems like a fair game, given todays 1,5TB HDDs. -- Tomasz Torcz -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
