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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
