Date: Fri, 27 Mar 2015 10:55:02 +0100 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-hackers@freebsd.org Cc: wojtek@puchar.net Subject: Re: Seagate Archive HDD Message-ID: <24923565183434755291@scdbackup.webframe.org> In-Reply-To: <alpine.BSF.2.20.1503270941190.719@laptop.wojtek.intra> References: <alpine.BSF.2.20.1503270941190.719@laptop.wojtek.intra>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Wojciech Puchar wrote: > 2) replacement for rsync or other backup tools [...] > Written data can have geom_uzip&cd9660 (or ffs) compatible > layout to be readable by just anything. The visible hardware constraints resemble those of BD-RE or DVD-RAM media (but on a much larger scale, of course). So multi-session ISO 9660 + Rock Ridge would be well suitable. A write run consists of one sequential tree-and-data write and one small update write of the PVD (superblock). One would either use the raw device resp. a partition or write the ISO into some data file of a file system. My own ISO 9660 backup program xorriso would bail out at 4 TiB, because of some signed 32 bit integers in the APIs which it uses. One would have to organize the backup into several smaller areas. Or one could simply make a new base backup when the file with the ISO filesystem grows near to 4 TiB. Incremental ISO 9660 works by adding a new file tree and the whole data content of changed files. So the storage efficiency is worse than rsync, especially with large data files which change frequently. On the other hand ISO 9660 multi-session by xorriso allows to retrieve the older backup states by mount_cd9660 option -s. xorriso can tell the necessary block number. But the "cd9660" reader in FreeBSD is very restricted in respect to location of directory trees (not above 4 GiB - 1) and to file size (not more than 4 GiB - 1 bytes). The tree restriction is because the byte location of directory records is used as 32 bit inode number which then is used again to address the directory record. The file size restriction is because multiple data extents per file are not supported. NetBSD offers an escape path from the tree problem by its generous 64-bit inode numbers. Linux obviously does not use the inode number for addressing purposes and thus can afford to work with byte address divided by 32. This results in a 128 GiB window for trees, where inode numbers are unique. Not a totally general solution, but sufficient for any imaginable real purpose. You can put a lot of file names and meta data into 128 GiB. xorriso can retrieve what it wrote. So if the inconvenience of a random-access archive backup is acceptable, then 4 TiB filesystem size is supposed to be the only restriction. Have a nice day :) Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24923565183434755291>