David Rees schrieb: (...)
>> I guess enabling write cache would help a lot, as then, the storage >> could commit the changes out of order (less seek) - but I don't trust it >> much. > > Where would you be enabling the write cache? It looks like you are > using iscsi (I'm not familar with it myself). If it's a battery-backed > write cache on the controller, then yes, that would be very helpful > and should be safe. I indeed use iSCSI. The storage is on the SAN, and it's accessible via iSCSI. BackupPC itself runs as a Xen guest. The SAN box itself is Thecus n5200 (I replaced the original firmware with Debian running the newest kernel, SCST as a iSCSI target + some other customizations) - it is a small, compact box with place for 5 hard disks. Unfortunately, there is something wrong with that device - sometimes it just freezes for an unknown reason (no logs, even on a serial console). I noticed that it only freezes when I put the box on a server rack. It doesn't freeze if I put the box somewhere else, i.e. directly on a concrete floor. So "the theory" is that it freezes due to some micro vibrations caused by the server rack. As the theory is rather weak, I wouldn't like to enable write cache. There is a small remark here though. I can enable write cache in two places: write cache in disks (how much cache can disks have?) and in iSCSI target (the target can have lots of memory, so write cache can work efficiently). If the system looses power, it is bad - disk write cache will be lost and iSCSI target cache will be lost. But as I have a UPS, it shouldn't happen. As this box freezes (well, not if it isn't placed on a rack, but it's just a "weak-perhaps-theory"), disks can write its cache, but iSCSI target can not (as the system doesn't work anymore). As a consequence, I have write cache enabled in disks, but disabled in iSCSI target. If write cache is enabled in the iSCSI target, and the box freezes, filesystem corruption happens. Obviously, it takes several hours to fsck it. But hey, doesn't ext3 have barrier support (in short, barriers mean that the filesystem will not be corrupted even if we use write cache)? Yes, it does have - but sadly, neither md (Linux software RAID) nor dm (device mapper, where LVM belongs) don't support barriers. As I have ext3 on LVM on RAID5, I can't use the barriers. Too bad. I have another such box, Thecus n5200Pro (it has a faster CPU), it doesn't seem to freeze. And I will build there a similar filesystem for backup, soon. > Can you give us more details on your disk array? Controller, disks, > RAID layout, ext3 fs creation options, etc... I said some of that already - but here are some missing parts. 5x 400 MB HDD (WDC WD4000YR) The controller uses sata_mv module (Marvell). Linux software RAID over it, LVM over it. Filesystem for backup is 1.2 TB big. The fs has these features: has_journal filetype needs_recovery sparse_super large_file. "needs_recovery" sounds like a very desired feature ;) > I noticed in your linux-kernel thread that you said that large writes > are are very slow (1MB/s). That certainly sounds abnormal. I would > expect at least 25MB/s and with an array that big, you probably have > at least 3 disks so it should be at least 2-3 times faster than that > for writing large files. On an empty filesystem on than NAS I can write with ~25 MB/s. I guess that backup filesystem is just very fragmented? On the other hand, it is only 60-70% full, so drop from ~25 MB/s (empty filesystem) to ~1.3 MB/s is indeed something odd. But hey, sequential writing isn't something very often used with BackupPC. Just how fast can you write a file downloaded from the internet (or even LAN) which is being compressed with bzip2 at the same time. Or better yet, when there are 10 such threads compressing with bzip2. > Have you also tried mounting the filesystem in data=writeback mode? > Accord to this whitepaper[1] it should significantly improve the > performance of creating/deleting small files at the expense of some > data integrity in the case of a crash (which should not be a big deal > since BackupPC does a good job of verifying the pool during backups). Yeah, I was a bit afraid of data integrity. Using commit=60 sounds like a good alternative. Would BackupPC detect a corrupted file which is unique? Even if yes, it would be corrupted, with no other copy, so... -- Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
