All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hubert Kario <hka@qbs.com.pl>
To: "David Pottage" <david@electric-spoon.com>
Cc: "Nikanth Karthikesan" <knikanth@novell.com>,
	"OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christoph Hellwig" <hch@lst.de>,
	"Chris Mason" <chris.mason@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH][RFC] Complex filesystem operations: split and join
Date: Thu, 17 Jun 2010 17:04:13 +0200	[thread overview]
Message-ID: <201006171704.14541.hka@qbs.com.pl> (raw)
In-Reply-To: <e4ea1892f15eaac945c151ea14a5d2d9.squirrel@www.chrestomanci.org>

On Tuesday 15 June 2010 17:16:06 David Pottage wrote:
> On 15/06/10 11:41, Nikanth Karthikesan wrote:
> > I had a one-off use-case, where I had no free-space, which made me
> > think along this line.
> >=20
> > 1. We have the GNU split tool for example, which I guess, many of u=
s
> > use to split larger files to be transfered via smaller thumb drives=
,
> > for example. We do cat many files into one, afterwards. [For this
> > usecase, one can simply dd with seek and skip and avoid split/cat
> > completely, but we dont.]
>=20
> I am not sure how you gain here as either way you have to do I/O to g=
et
> the split files on and off the thumb drive. It might make sense if th=
e
> thumb drive is formated with btrfs, and the file needs to be copied t=
o
> another filling system that can't handle large files (eg FAT-16), but=
 I
> would say that is unlikely.
>=20

But you do have to do only half as much of I/O with those features=20
implemented.

The old way is:
1. Have a file
2. split a file (in effect use twice as much drive space)
3. copy fragments to flash disks

The btrfs way would be:
1. Have a file
2. split the file by using COW and referencing blocks in the original f=
ile (in=20
effect using only a little more space after splitting)
3. copy fragments to flash disks

the amount of I/O in the second case is limited only to metadata operat=
ions,=20
in the first case, all data must be duplicated

--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=C3=B3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

System Zarz=C4=85dzania Jako=C5=9Bci=C4=85
zgodny z norm=C4=85 ISO 9001:2000
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Hubert Kario <hka@qbs.com.pl>
To: "David Pottage" <david@electric-spoon.com>
Cc: "Nikanth Karthikesan" <knikanth@novell.com>,
	"OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christoph Hellwig" <hch@lst.de>,
	"Chris Mason" <chris.mason@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH][RFC] Complex filesystem operations: split and join
Date: Thu, 17 Jun 2010 17:04:13 +0200	[thread overview]
Message-ID: <201006171704.14541.hka@qbs.com.pl> (raw)
In-Reply-To: <e4ea1892f15eaac945c151ea14a5d2d9.squirrel@www.chrestomanci.org>

On Tuesday 15 June 2010 17:16:06 David Pottage wrote:
> On 15/06/10 11:41, Nikanth Karthikesan wrote:
> > I had a one-off use-case, where I had no free-space, which made me
> > think along this line.
> > 
> > 1. We have the GNU split tool for example, which I guess, many of us
> > use to split larger files to be transfered via smaller thumb drives,
> > for example. We do cat many files into one, afterwards. [For this
> > usecase, one can simply dd with seek and skip and avoid split/cat
> > completely, but we dont.]
> 
> I am not sure how you gain here as either way you have to do I/O to get
> the split files on and off the thumb drive. It might make sense if the
> thumb drive is formated with btrfs, and the file needs to be copied to
> another filling system that can't handle large files (eg FAT-16), but I
> would say that is unlikely.
> 

But you do have to do only half as much of I/O with those features 
implemented.

The old way is:
1. Have a file
2. split a file (in effect use twice as much drive space)
3. copy fragments to flash disks

The btrfs way would be:
1. Have a file
2. split the file by using COW and referencing blocks in the original file (in 
effect using only a little more space after splitting)
3. copy fragments to flash disks

the amount of I/O in the second case is limited only to metadata operations, 
in the first case, all data must be duplicated

-- 
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

System Zarządzania Jakością
zgodny z normą ISO 9001:2000

WARNING: multiple messages have this Message-ID (diff)
From: Hubert Kario <hka@qbs.com.pl>
To: "David Pottage" <david@electric-spoon.com>
Cc: "Nikanth Karthikesan" <knikanth@novell.com>,
	"OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christoph Hellwig" <hch@lst.de>,
	"Chris Mason" <chris.mason@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH][RFC] Complex filesystem operations: split and join
Date: Thu, 17 Jun 2010 17:04:13 +0200	[thread overview]
Message-ID: <201006171704.14541.hka@qbs.com.pl> (raw)
In-Reply-To: <e4ea1892f15eaac945c151ea14a5d2d9.squirrel@www.chrestomanci.org>

On Tuesday 15 June 2010 17:16:06 David Pottage wrote:
> On 15/06/10 11:41, Nikanth Karthikesan wrote:
> > I had a one-off use-case, where I had no free-space, which made me
> > think along this line.
> > 
> > 1. We have the GNU split tool for example, which I guess, many of us
> > use to split larger files to be transfered via smaller thumb drives,
> > for example. We do cat many files into one, afterwards. [For this
> > usecase, one can simply dd with seek and skip and avoid split/cat
> > completely, but we dont.]
> 
> I am not sure how you gain here as either way you have to do I/O to get
> the split files on and off the thumb drive. It might make sense if the
> thumb drive is formated with btrfs, and the file needs to be copied to
> another filling system that can't handle large files (eg FAT-16), but I
> would say that is unlikely.
> 

But you do have to do only half as much of I/O with those features 
implemented.

The old way is:
1. Have a file
2. split a file (in effect use twice as much drive space)
3. copy fragments to flash disks

The btrfs way would be:
1. Have a file
2. split the file by using COW and referencing blocks in the original file (in 
effect using only a little more space after splitting)
3. copy fragments to flash disks

the amount of I/O in the second case is limited only to metadata operations, 
in the first case, all data must be duplicated

-- 
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

System Zarządzania Jakością
zgodny z normą ISO 9001:2000
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-06-17 15:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 15:05 [PATCH][RFC] Complex filesystem operations: split and join Nikanth Karthikesan
2010-06-09 15:05 ` Nikanth Karthikesan
2010-06-13 11:42 ` OGAWA Hirofumi
2010-06-15 10:41   ` Nikanth Karthikesan
2010-06-15 12:01     ` OGAWA Hirofumi
2010-06-15 15:16     ` David Pottage
2010-06-17 15:04       ` Hubert Kario [this message]
2010-06-17 15:04         ` Hubert Kario
2010-06-17 15:04         ` Hubert Kario
2010-06-22  1:26       ` Stewart Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006171704.14541.hka@qbs.com.pl \
    --to=hka@qbs.com.pl \
    --cc=chris.mason@oracle.com \
    --cc=david@electric-spoon.com \
    --cc=hch@lst.de \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=knikanth@novell.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.